From: | Philip Greer <philip(at)tildesoftware(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Why does it not use the index? |
Date: | 2003-07-21 17:06:07 |
Message-ID: | 20030721170607.GA18568@tildesoftware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
This one is irritating. Here's some psql output:
================================================================================
dumps=# \d fal_profdel
Table "fal_profdel"
Attribute | Type | Modifier
-----------+--------------------------+----------
sid | character(4) | not null
card_num | character(19) | not null
date_del | timestamp with time zone |
filename | character varying(30) |
Indices: fal_prfdel_cn,
fal_prfdel_date,
fal_prfdel_pk
dumps=# \d fal_prfdel_cn
Index "fal_prfdel_cn"
Attribute | Type
-----------+---------------
card_num | character(19)
unique btree
dumps=# explain select card_num from fal_profdel where card_num = 'removed_for_privacy';
NOTICE: QUERY PLAN:
Seq Scan on fal_profdel (cost=0.00..120546.39 rows=46649 width=12)
EXPLAIN
================================================================================
Now, why the heck is the select query not using the index? I've tried it by having an exact 19 character card_num as well - still explains as a 'Seq Scan' (tablespace scan) - and each query takes up to 37 seconds (thus confirming that it is indeed doing scans and not using the index).
I've tried dropping and re-creating the indexes, still it explains as tablespace scans.
I am running postgresql 7.1.3 - a bit old, I know, but I have had no reason to upgrade just yet.
By the way, the fal_profdel table has 4,664,867 rows in it currently - thus I really don't want full table scans!
--
-----------------------------------------------------------------------------
PG.. philip(at)tildesoftware(dot)com
Law of probable dispersal: Whatever it is that hits the fan will not be
evenly distributed.
From | Date | Subject | |
---|---|---|---|
Next Message | Nigel J. Andrews | 2003-07-21 17:07:18 | Re: Incomprehensible behaviour of a foreign key. |
Previous Message | Chris Gamache | 2003-07-21 17:05:40 | pg_dump dies on a renamed sequence... (7.2) |