Re: force the use of a particular index

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.