[forum:/forumpost/b9647a113b465950|forum post b9647a113b] so that it
provides a more complete fix that covers cases that were not resolved by
the original fix, and so that it does not cause performance regressions.
FossilOrigin-Name: 28db0d152d90fb5e62d03ea5caceabe8901be98522aef3dc2b54564fbc35355d
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
that do not have a WHERE clause, and so that it works on nested EXISTS
subqueries.
FossilOrigin-Name: c1d5295724f9cf7f49e0786d28016eff2d268a2b670f934d24c76787626089db
"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
