From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | "Surabhi Ahuja " <surabhi(dot)ahuja(at)iiitb(dot)ac(dot)in> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: regarding IN clause |
Date: | 2005-05-18 05:54:46 |
Message-ID: | 873bslcc49.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Surabhi Ahuja " <surabhi(dot)ahuja(at)iiitb(dot)ac(dot)in> writes:
> why is it not searching the indexes(index scan)? and how can i make such a
> query much faster?
130 values out of 3,000 is 4.3% of the table. If you have narrow records with,
say, 20 per page that would mean reading most of the pages out of the table.
Add in that it has to read in the index pages and it could be doing more i/o
than a simple sequential scan. Now consider that random access is about four
times slower than reading sequentially and you could be far behind.
set enable_indexscan = off;
explain analyze select ...
set enable_indexscan = on;
Note that it can be quite hard to get reliable timing information for such a
small table since the second time you run the query all the data will be in
RAM already.
If you find indexes are faster you might try lowering random_page_cost,
possibly as low as 1.2-2.0 but beware of using a single query to tune such
parameters. And beware tuning them on non-production conditions. When the data
grows and less of it fits in RAM you may have to raise it again.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2005-05-18 07:05:59 | Re: Logs |
Previous Message | Dann Corbit | 2005-05-18 05:26:06 | Re: regarding IN clause |