On 01/30/2015 10:49 PM, Dominique Devienne wrote:
On Fri, Jan 30, 2015 at 4:38 PM, Dan Kennedy <danielk1...@gmail.com> wrote:
On 01/29/2015 02:29 AM, farkas andras wrote:
[...] but searches based on ROWID are atrociously slow and hog massive
amounts of memory [...]
Looks like range constraints on rowids were only taken into account when
there was also a MATCH term in the WHERE clause. Now fixed here:
http://www.sqlite.org/src/info/85dc12625d300f
The fix should be in 3.8.9.
Just curious Dan. The tests added do not seem to check the query plans
despite the report being about a performance issue. I only skimmed them,
and I'm unfamiliar with TCL and the exact specifics of SQLite testing, so I
could well have missed them, but I do recall seen other perf tests checking
execution plans, in addition to checking correctness. Did I miss them?
Fair point. It would be better if there were tests to show that the
queries were being correctly optimized.
But the change was fairly trivial, and I didn't think there was much
chance that it would fail to optimize the queries correctly. Also, it's
a pretty obscure optimization (one complaint in how many years?), so I
figured it wasn't all that important. Finally it's fiddly to test in
this case, as the EXPLAIN QUERY PLAN (or even EXPLAIN) output is not
sufficient to figure out if it's working properly or not. So I just
checked by hand that the optimization is working.
On the other hand, that the change could contain some bug related to
integer overflow or some other boundary condition is a real risk. So the
tests focus on that.
Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
