Thank you for the quick fix and the info, I will wait for 3.8.9 to trickle down 
into DBD::SQLite. AF
Dan Kennedy <> írta:
>On 01/30/2015 10:49 PM, Dominique Devienne wrote:
>> On Fri, Jan 30, 2015 at 4:38 PM, Dan Kennedy <> 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:
>>> 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&#39;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&#39;t think there was much 
>chance that it would fail to optimize the queries correctly. Also, it&#39;s 
>a pretty obscure optimization (one complaint in how many years?), so I 
>figured it wasn&#39;t all that important. Finally it&#39;s fiddly to test in 
>this case, as the EXPLAIN QUERY PLAN (or even EXPLAIN) output is not 
>sufficient to figure out if it&#39;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.
>sqlite-users mailing list
sqlite-users mailing list

Reply via email to