On 2014/09/20 23:08, Richard Hipp wrote:
On Sat, Sep 20, 2014 at 12:45 PM, Merike <gas...@smail.ee> wrote:
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.
Richard, I think the OP meant to ask whether or not running analyze fixed the bug, maybe a slight misunderstanding and you probably
assumed correct understanding as a benefit of the doubt scenario - so allow me to just add the following in case the OP did think of
it the other way:
Merike: Running Analyze did not fix the bug, it simply changed some internal-use values that allowed the bug to be circumvented. If
you re-make a table as you had without running analyze, the problem will surely remain using the same codebase. Updating your SQLite
code from the Trunk specified by Richard will fix the bug for real, meaning that analyze would make no real difference (for the
specifed use case). Naturally the trunk is also included in the next release which is probably due within the next month at which
time the bug fix will be standard across all released versions.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
