On 2016-01-20 18:14, Yuri wrote:
> Does SQLite optimizer look at the row counts? (I think it does because
> the plans are different when there are no rows present).
> How to correct the problem?
If you want to do a manual optimization, the following describes how to
set the order of joins
Have you tried running ANALYZE on a representative dataset? This will determine
the "shape" of your tables and allow the query planner to make better guesses
of the costs associated with each join.
If, after ANALYZE, you still feel the need to improve over the query planners'
ordering, you can
On 1/20/16, Yuri wrote:
>
> Does SQLite optimizer look at the row counts?
It does if they are available. Run ANALYZE to generate the row counts.
--
D. Richard Hipp
drh at sqlite.org
On 01/20/2016 09:21, Hick Gunter wrote:
> ave you tried running ANALYZE on a representative dataset? This will
> determine the "shape" of your tables and allow the query planner to make
> better guesses of the costs associated with each join.
>
> If, after ANALYZE, you still feel the need to
I have the select query over the linked chain of tables with all needed
indices present.
All but one tables (m,h,e,w) have row count ~300,000-700,000, mt table
has only ~150 rows.
Obviously, based on the row count, scan should begin from the table mt.
However, SQLite actually scans beginning
5 matches
Mail list logo
