From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Philip Greer <philip(at)tildesoftware(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Why does it not use the index? |
Date: | 2003-07-21 18:00:56 |
Message-ID: | 20030721105913.R4254-100000@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 21 Jul 2003, Philip Greer wrote:
> 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).
Have you vacuum analyzed the table recently? What does explain show if you
do set enable_seqscan=off; before the explain and then how long does the
query actually take to run with seqscan disabled.
From | Date | Subject | |
---|---|---|---|
Next Message | DeJuan Jackson | 2003-07-21 18:11:18 | Re: [GENERAL] INSTEAD rule bug? |
Previous Message | Nigel J. Andrews | 2003-07-21 17:07:18 | Re: Incomprehensible behaviour of a foreign key. |