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: | Raw Message | Whole Thread | 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 |