---
From: Richard Hipp
To: SQLite mailing list
Cc: alessandro.far...@gavazziacbu.it
Date: 27/07/2016 21:33
Subject:Re: [sqlite] sqlite 3.13.0 does not use indexes as
3.8.11.1 does
Sent by:drhsql...@gmail.com
On 7/26/16, Alessandro Fard
On 7/26/16, Richard Hipp wrote:
>
> Two possible fixes are:
>
> (1) Disable the new query algorithm introduced in 3.12. This does not
> fix the cost estimate for the 3.11 algorithm, but as there are no
> other reasonable competing algorithm choices, the 3.11 algorithm will
> still win. The probl
On 7/26/16, Alessandro Fardin wrote:
> After updating from sqlite 3.8.11.1 to sqlite 3.13.0.
>
> The Query planner with the same SELECT statement on same table with the
> same indexes does not use index at all, but parse the entire table.
> Of course this causes a dramatically slow down of the ap
On 7/26/16, Richard Hipp wrote:
> Consider:
>
> SELECT * FROM t1 WHERE b=99 AND c<>22 ORDER BY a LIMIT 1;
>
Or, how about this one:
SELECT * FROM t1 WHERE appfunc(b)=99 AND c<>22 ORDER BY a LIMIT 1;
In this case, SQLite has the option of doing a table look-up in order
to evaluate c<>22 o
On 7/26/16, Alessandro Fardin wrote:
>
> The Query planner with the same SELECT statement on same table with the
> same indexes does not use index at all, but parse the entire table.
> Of course this causes a dramatically slow down of the application.
>
When you say "of course this causes a slowd
SQLite version 3.14.0 2016-07-26 04:49:43
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table t(x,y,z);
sqlite> create index i1 on t(x,y);
sqlite> explain query plan select * from t where y=100 or
Query plan changed, It's a bug
发件人: Alessandro Fardin<mailto:alessandro.far...@gavazziacbu.it>
发送时间: 2016/7/26 16:37
收件人:
sqlite-users@mailinglists.sqlite.org<mailto:sqlite-users@mailinglists.sqlite.org>
主题: [sqlite] sqlite 3.13.0 does n
On Tue, 26 Jul 2016 10:37:12 +0200
Alessandro Fardin wrote:
> After updating from sqlite 3.8.11.1 to sqlite 3.13.0.
>
> The Query planner with the same SELECT statement on same table with
> the same indexes does not use index at all, but parse the entire
> table. Of course this causes a dramati
On Tue, Jul 26, 2016 at 10:37 AM, Alessandro Fardin
wrote:
> As temporary work around we have have added to the query the INDEXED BY
> energy_d_dateTimeIdx statement.
>
> In sqlite 3.8.11.1 the select was issued by using the
> energy_d_dateTimeIdx index
Any chance the optimizer thinks the table
After updating from sqlite 3.8.11.1 to sqlite 3.13.0.
The Query planner with the same SELECT statement on same table with the
same indexes does not use index at all, but parse the entire table.
Of course this causes a dramatically slow down of the application.
As temporary work around we have
10 matches
Mail list logo
