From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Chris Jones <chris(at)mt(dot)sri(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: strange query plans |
Date: | 2000-11-30 23:34:33 |
Message-ID: | Pine.BSF.4.21.0011301532550.48480-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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).
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2000-11-30 23:35:41 | Re: inheritance and foreign keys |
Previous Message | Roberto Mello | 2000-11-30 23:25:15 | Re: String function page incorrect? |