1
0
mirror of https://github.com/sqlite/sqlite.git synced 2025-07-29 08:01:23 +03:00

Fix for the problem identified in

[forum:/forumpost/0cd8e058bf|forum post 0cd8e058bf]:
When evaluating an multi-index OR, do not push down auxiliary WHERE clause
terms that involve subqueries into the OR-subqueries.  Otherwise, the
covering-index optimizer might convert table-references into index-references
for the particular OR index that is active for the branch in which the
subquery subroutine is coded, and those index-references
will not work if the subquery subroutine is invoked from a different OR branch
that uses a different index.

FossilOrigin-Name: 61a1c6dbd089979cbeb8b0c0c5ee1ab1abcb466be1d21a3a851be73c27e67a6c
This commit is contained in:
drh
2022-03-03 15:59:22 +00:00
parent 1902516d16
commit c9bcc5aab7
4 changed files with 42 additions and 10 deletions

View File

@ -23361,4 +23361,28 @@ do_eqp_test where7-3.2 {
`--USE TEMP B-TREE FOR ORDER BY
}
# 2022-03-03 https://sqlite.org/forum/forumpost/36937b197273d403
#
# In the multi-index OR, if there is an auxiliary WHERE clause term
# that includes a subquery and that subquery is pushed down into the
# OR-clause subqueries, WHERE subquery might get coded as a subroutine.
# In that case, the covering-index optimizer will attempt to change
# table-references into index-references. But it will do so for the
# index of the OR branch in which the subquery is coded. If the
# subquery subroutine is called from a different OR branch, the
# index might be different and the index-reference will no longer
# work. tag-20220303a
#
reset_db
do_execsql_test 4.1 {
CREATE TABLE t0(w);
INSERT INTO t0(w) VALUES(1);
CREATE TABLE t1(x INT, y INT PRIMARY KEY, z);
INSERT INTO t1 VALUES(0,111,222);
CREATE INDEX t1zxy ON t1(z,x,y);
SELECT y FROM t1
WHERE (z=222 OR y=111)
AND (false OR EXISTS(SELECT 1 FROM t0 WHERE t1.y));
} {111}
finish_test