# 2007 November 29 # # The author disclaims copyright to this source code. In place of # a legal notice, here is a blessing: # # May you do good and not evil. # May you find forgiveness for yourself and forgive others. # May you share freely, never taking more than you give. # #*********************************************************************** # This file tests the optimisations made in November 2007 of expressions # of the following form: # # IN (SELECT FROM ) # # $Id: in3.test,v 1.1.1.1 2012/02/21 17:04:16 misho Exp $ set testdir [file dirname $argv0] source $testdir/tester.tcl ifcapable !subquery { finish_test return } # Return the number of OpenEphemeral instructions used in the # implementation of the sql statement passed as a an argument. # proc nEphemeral {sql} { set nEph 0 foreach op [execsql "EXPLAIN $sql"] { if {$op eq "OpenEphemeral"} {incr nEph} } set nEph } # This proc works the same way as execsql, except that the number # of OpenEphemeral instructions used in the implementation of the # statement is inserted into the start of the returned list. # proc exec_neph {sql} { return [concat [nEphemeral $sql] [execsql $sql]] } do_test in3-1.1 { execsql { CREATE TABLE t1(a PRIMARY KEY, b); INSERT INTO t1 VALUES(1, 2); INSERT INTO t1 VALUES(3, 4); INSERT INTO t1 VALUES(5, 6); } } {} # All of these queries should avoid using a temp-table: # do_test in3-1.2 { exec_neph { SELECT rowid FROM t1 WHERE rowid IN (SELECT rowid FROM t1); } } {0 1 2 3} do_test in3-1.3 { exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1); } } {0 1 3 5} do_test in3-1.4 { exec_neph { SELECT rowid FROM t1 WHERE rowid+0 IN (SELECT rowid FROM t1); } } {0 1 2 3} do_test in3-1.5 { exec_neph { SELECT a FROM t1 WHERE a+0 IN (SELECT a FROM t1); } } {0 1 3 5} # Because none of the sub-select queries in the following statements # match the pattern ("SELECT FROM
"), the following do # require a temp table. # do_test in3-1.6 { exec_neph { SELECT rowid FROM t1 WHERE rowid IN (SELECT rowid+0 FROM t1); } } {1 1 2 3} do_test in3-1.7 { exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a+0 FROM t1); } } {1 1 3 5} do_test in3-1.8 { exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 WHERE 1); } } {1 1 3 5} do_test in3-1.9 { exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 GROUP BY a); } } {1 1 3 5} # This should not use a temp-table. Even though the sub-select does # not exactly match the pattern "SELECT FROM
", in # this case the ORDER BY is a no-op and can be ignored. do_test in3-1.10 { exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 ORDER BY a); } } {0 1 3 5} # These do use the temp-table. Adding the LIMIT clause means the # ORDER BY cannot be ignored. do_test in3-1.11 { exec_neph {SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 ORDER BY a LIMIT 1)} } {1 1} do_test in3-1.12 { exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 ORDER BY a LIMIT 1 OFFSET 1) } } {1 3} # Has to use a temp-table because of the compound sub-select. # ifcapable compound { do_test in3-1.13 { exec_neph { SELECT a FROM t1 WHERE a IN ( SELECT a FROM t1 UNION ALL SELECT a FROM t1 ) } } {1 1 3 5} } # The first of these queries has to use the temp-table, because the # collation sequence used for the index on "t1.a" does not match the # collation sequence used by the "IN" comparison. The second does not # require a temp-table, because the collation sequences match. # do_test in3-1.14 { exec_neph { SELECT a FROM t1 WHERE a COLLATE nocase IN (SELECT a FROM t1) } } {1 1 3 5} do_test in3-1.15 { exec_neph { SELECT a FROM t1 WHERE a COLLATE binary IN (SELECT a FROM t1) } } {0 1 3 5} # Neither of these queries require a temp-table. The collation sequence # makes no difference when using a rowid. # do_test in3-1.16 { exec_neph {SELECT a FROM t1 WHERE a COLLATE nocase IN (SELECT rowid FROM t1)} } {0 1 3} do_test in3-1.17 { exec_neph {SELECT a FROM t1 WHERE a COLLATE binary IN (SELECT rowid FROM t1)} } {0 1 3} # The following tests - in3.2.* - test a bug that was difficult to track # down during development. They are not particularly well focused. # do_test in3-2.1 { execsql { DROP TABLE IF EXISTS t1; CREATE TABLE t1(w int, x int, y int); CREATE TABLE t2(p int, q int, r int, s int); } for {set i 1} {$i<=100} {incr i} { set w $i set x [expr {int(log($i)/log(2))}] set y [expr {$i*$i + 2*$i + 1}] execsql "INSERT INTO t1 VALUES($w,$x,$y)" } set maxy [execsql {select max(y) from t1}] db eval { INSERT INTO t2 SELECT 101-w, x, $maxy+1-y, y FROM t1 } } {} do_test in3-2.2 { execsql { SELECT rowid FROM t1 WHERE rowid IN (SELECT rowid FROM t1 WHERE rowid IN (1, 2)); } } {1 2} do_test in3-2.3 { execsql { select rowid from t1 where rowid IN (-1,2,4) } } {2 4} do_test in3-2.4 { execsql { SELECT rowid FROM t1 WHERE rowid IN (select rowid from t1 where rowid IN (-1,2,4)) } } {2 4} #------------------------------------------------------------------------- # This next block of tests - in3-3.* - verify that column affinity is # correctly handled in cases where an index might be used to optimise # an IN (SELECT) expression. # do_test in3-3.1 { catch {execsql { DROP TABLE t1; DROP TABLE t2; }} execsql { CREATE TABLE t1(a BLOB, b NUMBER ,c TEXT); CREATE UNIQUE INDEX t1_i1 ON t1(a); /* no affinity */ CREATE UNIQUE INDEX t1_i2 ON t1(b); /* numeric affinity */ CREATE UNIQUE INDEX t1_i3 ON t1(c); /* text affinity */ CREATE TABLE t2(x BLOB, y NUMBER, z TEXT); CREATE UNIQUE INDEX t2_i1 ON t2(x); /* no affinity */ CREATE UNIQUE INDEX t2_i2 ON t2(y); /* numeric affinity */ CREATE UNIQUE INDEX t2_i3 ON t2(z); /* text affinity */ INSERT INTO t1 VALUES(1, 1, 1); INSERT INTO t2 VALUES('1', '1', '1'); } } {} do_test in3-3.2 { # No affinity is applied before comparing "x" and "a". Therefore # the index can be used (the comparison is false, text!=number). exec_neph { SELECT x IN (SELECT a FROM t1) FROM t2 } } {0 0} do_test in3-3.3 { # Logically, numeric affinity is applied to both sides before # the comparison. Therefore it is possible to use index t1_i2. exec_neph { SELECT x IN (SELECT b FROM t1) FROM t2 } } {0 1} do_test in3-3.4 { # No affinity is applied before the comparison takes place. Making # it possible to use index t1_i3. exec_neph { SELECT x IN (SELECT c FROM t1) FROM t2 } } {0 1} do_test in3-3.5 { # Numeric affinity should be applied to each side before the comparison # takes place. Therefore we cannot use index t1_i1, which has no affinity. exec_neph { SELECT y IN (SELECT a FROM t1) FROM t2 } } {1 1} do_test in3-3.6 { # Numeric affinity is applied to both sides before # the comparison. Therefore it is possible to use index t1_i2. exec_neph { SELECT y IN (SELECT b FROM t1) FROM t2 } } {0 1} do_test in3-3.7 { # Numeric affinity is applied before the comparison takes place. # Making it impossible to use index t1_i3. exec_neph { SELECT y IN (SELECT c FROM t1) FROM t2 } } {1 1} #--------------------------------------------------------------------- # # Test using a multi-column index. # do_test in3-4.1 { execsql { CREATE TABLE t3(a, b, c); CREATE UNIQUE INDEX t3_i ON t3(b, a); } execsql { INSERT INTO t3 VALUES(1, 'numeric', 2); INSERT INTO t3 VALUES(2, 'text', 2); INSERT INTO t3 VALUES(3, 'real', 2); INSERT INTO t3 VALUES(4, 'none', 2); } } {} do_test in3-4.2 { exec_neph { SELECT 'text' IN (SELECT b FROM t3) } } {0 1} do_test in3-4.3 { exec_neph { SELECT 'TEXT' COLLATE nocase IN (SELECT b FROM t3) } } {1 1} do_test in3-4.4 { # A temp table must be used because t3_i.b is not guaranteed to be unique. exec_neph { SELECT b FROM t3 WHERE b IN (SELECT b FROM t3) } } {1 none numeric real text} do_test in3-4.5 { execsql { CREATE UNIQUE INDEX t3_i2 ON t3(b) } exec_neph { SELECT b FROM t3 WHERE b IN (SELECT b FROM t3) } } {0 none numeric real text} do_test in3-4.6 { execsql { DROP INDEX t3_i2 } } {} # The following two test cases verify that ticket #2991 has been fixed. # do_test in3-5.1 { execsql { CREATE TABLE Folders( folderid INTEGER PRIMARY KEY, parentid INTEGER, rootid INTEGER, path VARCHAR(255) ); } } {} do_test in3-5.2 { catchsql { DELETE FROM Folders WHERE folderid IN (SELECT folderid FROM Folder WHERE path LIKE 'C:\MP3\Albums\' || '%'); } } {1 {no such table: Folder}} finish_test