21.09.2014 15:12, RSmith kirjutas: > 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. So, as I understand it analyze allows the bug to be circumvented on example database without upgrading sqlite itself. What I'm seeing with original database is that analyze does not allow circumvention of the bug there. Which could mean that the bug fixed is not the only one affecting original database even if it's the only one affecting example one. If both of the databases were affected by the exact same bug I would expect that analyze would allow circumvention in both cases, not just with example database.
Now I could very well be wrong about that as you say in your other reply that "It might simply be that Analyze did not get your QP to react on that size DB as it did for us". You seem to be saying that analyze behaves differently depending on database size. This would explain why analyze didn't allow circumvention on original database. In terms of size "backlog" table has 160 472 rows in the example I provided while originally it has ~1 100 000 rows. As I discovered it's much simpler to build sqlite than I expected I just checked original database with new version. And the query was fast there so the fix actually works on original database as well :) Merike _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
