| From: | Dan Fairs <dan(dot)fairs(at)gmail(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Unexpected sequence scan |
| Date: | 2012-05-04 14:56:12 |
| Message-ID: | 16162C81-E179-4517-8E3C-C343D06E916B@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hi Tom, Kevin,
>> I have a query which is running slowly, and the query plan shows an
> unexpected sequence scan where I'd have expected the planner to use an
> index. Setting enable_seqscan=off causes the planner to use the index as
> expected.
>
> That hashjoin plan doesn't look at all unreasonable to me. The fact
> that it actually comes out a lot slower than the nestloop with inner
> indexscan suggests that you must be running with the large table
> completely cached in RAM. If that's the normal state of affairs for your
> database, you should consider decreasing the random_page_cost setting
> so that the planner will plan appropriately.
>
A very quick test of the settings that Kevin posted produce a much better plan and faster response to that query (at least on my dev machine) I'll read up more on those settings before changing production, but it looks good - thanks very much!
Cheers,
Dan
--
Dan Fairs | dan(dot)fairs(at)gmail(dot)com | www.fezconsulting.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Jones | 2012-05-04 15:01:00 | Partitioned/inherited tables with check constraints causing slower query plans |
| Previous Message | Tom Lane | 2012-05-04 14:43:19 | Re: Unexpected sequence scan |