On Fri, 2003-07-11 at 13:17, Scott Cain wrote:
> The problem (at least as it appears to me) is not that it is performing
> a table scan instead of an index scan, it is that it is using the wrong
> index. Here is the output from EXPLAIN ANALYZE:
>
> QUERY PLAN
>
------------------------------------------------------------------------------------------------------------------------------------------------------------
> Unique (cost=494008.47..494037.59 rows=166 width=54) (actual time=114660.37..114660.38 rows=1 loops=1)
> -> Sort (cost=494008.47..494012.63 rows=1664 width=54) (actual time=114660.37..114660.37 rows=1 loops=1)
> Sort Key: f.name, fl.fmin, fl.fmax, fl.strand, f.type_id, f.feature_id
> -> Nested Loop (cost=0.00..493919.44 rows=1664 width=54) (actual time=2596.13..114632.90 rows=1 loops=1)
> -> Index Scan using feature_pkey on feature f (cost=0.00..134601.43 rows=52231 width=40) (actual
time=105.74..56048.87rows=13825 loops=1)
> Filter: (type_id = 219)
> -> Index Scan using featureloc_idx1 on featureloc fl (cost=0.00..6.87 rows=1 width=14) (actual
time=4.23..4.23rows=0 loops=13825)
> Index Cond: ("outer".feature_id = fl.feature_id)
> Filter: ((srcfeature_id = 6) AND (fmin <= 2585581) AND (fmax >= 2565581))
> Total runtime: 114660.91 msec
> it is using on featureloc (featureloc_idx1) is on the foreign key
> feature_id. It should instead be using another index, featureloc_idx3,
> which is built on (srcfeature_id, fmin, fmax).
Nope.. The optimizer is right in the decision to use featureloc_idx1.
You will notice it is expecting to retrieve a single row from this
index, but the featureloc_idx3 is bound to be larger (due to indexing
more data), thus take more disk reads for the exact same information (or
in this case, lack thereof).
What is taking a long time is the scan on feature_pkey. It looks like it
is throwing away a ton of rows that are not type_id = 219. Either that,
or you do a pile of deletes and haven't run REINDEX recently.
Create an index consisting of (feature_id, type_id). This will probably
make a significant different in execution time.