21.09.2014 00:08, Richard Hipp kirjutas: > On Sat, Sep 20, 2014 at 12:45 PM, Merike <gas...@smail.ee> wrote: > >> 19.09.2014 04:21, Richard Hipp kirjutas: >>> A simple script to reproduce the problem in the latest SQLite is as >>> follows: CREATE TABLE t1(a INTEGER PRIMARY KEY, b INTEGER, c INTEGER, >>> d INTEGER); CREATE INDEX t1b ON t1(b); CREATE TABLE t2(x INTEGER >>> PRIMARY KEY, y); explain query plan SELECT * FROM t1, t2 WHERE x=c AND >>> b=?1 ORDER BY a; .print ---------------------- CREATE INDEX t1bd ON >>> t1(b,d); explain query plan SELECT * FROM t1, t2 WHERE x=c AND b=?1 >>> ORDER BY a; If you copy/paste the above script into an sqlite3 >>> command-line shell, you'll see that, for some reason, the query >>> planner decides to sort manually rather than using an index for >>> sorting after the t1bd index is added. We are still investigating to >>> try understand why that is. Please note that if you run ANALYZE on >>> your sample database, the query is fast again. On my (Ubuntu) desktop, >>> the query takes 648 milliseconds before being analyzed and 600 >>> microseconds afterwards - a 1000-fold speedup. >> A question: is the query being fast again after analyze call indicative >> of the bug being fixed? Because I tried it on my original database too >> and there I don't see a speedup after analyze. Should I try to minimize >> it to a smaller database again where the bug still occurs, even after >> analyze? Or will the change you made fix my original database speed as >> well despite the analyze call not helping it? >> > The change fixes the problem (for us) *without* requiring ANALYZE. > Right, that's not what I was trying to ask so I'll try to explain again.
Is there a way to tell if this fix helps the query speed only on the example database I provided or also the original one without waiting for a new release of sqlite? Since you said that analyze helps the example database even without code fix I tried running analyze on original database too, hoping it might speed up that as well. And there it did not help. This might mean nothing, I don't know sqlite well enough to tell, but could it also mean that the fix (when released) might not speed up the same query on my original database? The table structure is the same there but data is different and there's more of it. It could very well be that waiting for the release is the only way to find it out as I'm not interested enough to try to build sqlite myself but I was trying to figure out if there's another way :) Otherwise there could be a chance that next release comes around and might not help the query on actual database and then I would need to post here again and wait for another release. Merike _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users