planner accept a WhereLoop for a row-value IN operator that uses the same
index column more than once.
FossilOrigin-Name: d2adf61f21a3ce901a2b08199ad0de191e88ef16e097c5f7a75c95ad958eff12
it causes a performance regression. Add new test cases for row-value lookups of
indexes that contain redundant columns, three of which are currently failing. This
branch is seeking an improved solution to the redundant index column problem for
row-value lookups.
FossilOrigin-Name: ad8ddcefab5cc526b1cd77731e00939c672e61ca83350d28961b67635d20da03
"expr IN ()" to "false", take care not to delete aggregate functions
in the "expr" as doing so can change the meaning of the query.
See [forum:/forumpost/f4878de3e7dd4764|forum thread f4878de3e7].
FossilOrigin-Name: 77397bd67d918db57d5ac545d6d963194806fdabcdaa8f822b6b09e4cfe8b715
and return SQLITE_MISUSE if too large.
[forum:/forumpost/b617e497287235d0|Forum post b617e49728].
FossilOrigin-Name: 6a5701e6c7be25cba93e55438f950966e1dacb32eb2b23a8acc8ac53da6f0a85
in queries that make use of RIGHT JOIN. Problem reported by
[forum:/forumpost/68f29a2005|forum post 68f29a2005].
FossilOrigin-Name: 9441fff52cc4e19c44df1a77ffe474f409d519b270c7166ce17f99e6ea48fc1e
NATURAL JOINs to the left of RIGHT JOINs where source tables are views
or subqueries. Initial problem report in
[forum:/forumpost/829306db47|forum post 829306db47].
FossilOrigin-Name: f184d1d236e47962658a4639d9533f67a525b74cfe0f06c93e9b85fdcd02a15f
a LEFT JOIN even if the RHS contains a virtual table. This was previously
disallowed by [9dbae1df75219e2a] as a performance optimization. It
turns out that the constraint causes performance issues, and we do not have
a record of any performance issue that it solves.
FossilOrigin-Name: 1ddaa92057e550ea281d45d9860eafe69399224725548a93dd91c47a34e52152
side is coming from a RIGHT JOIN, be sure to set the EP_CanBeNull flag so that
the optimizer knows to check for NULL even if the column has a NOT NULL
constraint. Fix for the problem reported by
[forum:/forumpost/4fc70203b61c7e12|forum post 4fc70203b61]
FossilOrigin-Name: 60adc78a22956429d34ccc4e2c193c5994c11c3b3cff7901d47fad7d92dba935
in addition to LEFT JOIN. Problem reported by
[forum:/forumpost/7dee41d32506c4ae|forum post 2025-05-29T15:10:14Z].
FossilOrigin-Name: 29b1e1b97619d03a97ef562a5707929e241d019179b4ff1d0bc2a8c008441431
Adjust ./configure so that it does not check for malloc_usable_size().
FossilOrigin-Name: 7e9845433ff26bdc5fe8654281d584394b77e3b206d09669b4468e0271c6eb37
See [forum:/forumpost/792a09cb3df9e69f|forum post 792a09cb3d] for
a description of the problem. Also improve comments related
to [baa83b460c677c21] which was origin of the problem.
FossilOrigin-Name: cdef486e212fe4b26605065d9cff08f608cb80df48ee64e4be63637769bdfacc
the FUZZDB environment variable (as that can be awkward to do on Windows).
Further improvements to the testrunner.tcl documentation.
FossilOrigin-Name: 6fb84156a262ff89d1a2d1df6fbfac4c1a43fb55b9d15205508662e2c9b0894f
that env-var points to a fuzzcheck database, then suppliment the fuzzcheck
tests with that extra database.
FossilOrigin-Name: c08530dd6a71cb547d164e2313657c917f280e7988211bf199c8776e78a4e2a6
the ROWID as one of it columns, and then the columns of that UNIQUE are
used in a row-value IN operator as a WHERE clause constraint. Reported by
[forum:/forumpost/b9647a113b465950|forum post b9647a113b]. Problem
introduced by [723f1be3d4a905a6], part of ticket [da78413751863].
FossilOrigin-Name: d22475b81c4e26ccc50f3b5626d43b32f7a2de34e5a764539554665bdda735d5
that uses the UNION operator. Follow-up to [f911f1c4977fbcae] and it's output row
estimate changes associated with DISTINCT queries.
FossilOrigin-Name: 92513f6bce7ecc778e78af3a77bc66ff65585fffa2e3138f8acb9e617121eeb0
