FWIW: The following script demonstrates the problem: CREATE TABLE t1(x INTEGER, y INTEGER); CREATE INDEX t1xy ON t1(x,y); CREATE INDEX t1y ON t1(y);
CREATE TABLE t2(x INTEGER PRIMARY KEY, y INTEGER); CREATE TABLE t3(x INTEGER PRIMARY KEY, y INTEGER); CREATE INDEX t3y ON t3(y); .wheretrace off explain query plan SELECT * FROM t1, t2, t3 WHERE t1.x IN (1,2,3,4) AND t1.y IN (1,2,3,4) AND t1.y = t2.x AND t3.y = 0 AND t3.x = t1.y ; .print --------------------------------- explain query plan SELECT * FROM t1, t2, t3 WHERE t1.x IN (1,2,3,4) AND t1.y = t2.x AND t1.y IN (1,2,3,4) AND t3.y = 0 AND t3.x = t1.y ; This is not technically a bug, since it gets the right answer in all cases. It is just that sometimes the answer arrives more slowly than you would like. The problem stems from the two constraints on t1.y, and the fact that the query optimizer has to choose between them. On Fri, Apr 19, 2013 at 9:30 AM, Mario M. Westphal <m...@mwlabs.de> wrote: > > I'm currently uploading the database and will send you a link to it. > > -- Mario > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
