From: | Chris Jones <chris(at)mt(dot)sri(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | strange query plans |
Date: | 2000-11-29 16:56:26 |
Message-ID: | a5flmu2k98l.fsf@merry.mt.sri.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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)
EXPLAIN
fastfacts=> select count(*) from event where type = 'IPOETC_EVENT';
count
-------
16
(1 row)
fastfacts=> \d event_type_key
Index "event_type_key"
Attribute | Type
-----------+------
type | text
btree
fastfacts=> select count(*) from event;
count
--------
126580
(1 row)
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?
Please CC: me, as I'm not on this list.
Chris
--
----------------------------------------------------- chris(at)mt(dot)sri(dot)com
Chris Jones SRI International, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Kislo | 2000-11-29 16:59:43 | Unanswered questions about Postgre |
Previous Message | Steve Heaven | 2000-11-29 16:46:15 | How do I install pl/perl |