Re: strange query plans

On 30 Nov 2000, Chris Jones wrote:

> PG seems to be choosing a sub-optimal query plan.  It's doing a
> sequential scan of a 120000-tuple table, instead of an index scan for
> the 16 matching rows.  Running PG 7.0.2:
>
> fastfacts=> vacuum analyze event;
> VACUUM
> fastfacts=> explain select type from event where type = 'IPOETC_EVENT';
> NOTICE:  QUERY PLAN:
>
> Seq Scan on event  (cost=0.00..6664.25 rows=6224 width=12)

> I know that PG is frequently smarter than I am, but this doesn't seem
> like a case where it's made a good decision.  What am I missing?

postgres is expecting 6224 rows to match rather than the 16 that are
actually there.  Usual questions are has this table been vacuum analyzed
recently and is there a very common value that is much more common
than other data in the column (this throws off the estimates).