From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | John Oakes <john(at)networkproductions(dot)net> |
Cc: | <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Index doesn't appear to be working. |
Date: | 2002-03-03 07:50:03 |
Message-ID: | 20020302234538.Y58150-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Sat, 2 Mar 2002, John Oakes wrote:
> I have a table with a column titled 'passfail' that only contains either a P
> for pass or an F for fail. The table name is 'one'. I created the index on
> the table with:
>
> CREATE INDEX one_passfail_idx ON one USING btree (passfail);
>
> I then do:
>
> VACUUM ANALYZE one;
>
> Then I do an explain on this query:
>
> SELECT * FROM one where passfail = 'P';
>
> and it tells me:
>
> Seq Scan on one (cost=0.00..263.02 rows=5613 width=56)
>
> Shouldn't it tell me
>
> Index Scan using one_passfail_idx on one?
>
> Why isn't it using the index? This query returns about 5,600 of 10,000
> records. It is faster to just do a seq scan because it returns such a high
> percentage or records? Thanks, I appreciate the help!
Usually the seq scan will be faster in this kind of situation. Because
the system needs to load the matching rows anyway, it's likely to result
in reading all the blocks of the table and paying a penalty for seeking
around the file.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-03-03 16:02:43 | Re: Index doesn't appear to be working. |
Previous Message | Masaru Sugawara | 2002-03-03 06:00:01 | Re: using LIMIT only on primary table |