From: | Steve Singer <ssinger(at)ca(dot)afilias(dot)info> |
---|---|
To: | "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: slow bitmap heap scans on pg 9.2 |
Date: | 2013-04-10 15:56:32 |
Message-ID: | 51658BB0.4000808@ca.afilias.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 13-04-10 09:56 AM, ktm(at)rice(dot)edu wrote:
> On Wed, Apr 10, 2013 at 09:49:55AM -0400, Steve Singer wrote:
>
> Hi Steve,
>
> The one thing that stands out to me is that you are working with 200GB of
> data on a machine with 4-8GB of ram and you have the random_page_cost set
> to 2.0. That is almost completely uncached and I would expect a value of
> 10 or more to be closer to reality.
Setting random_page_cost to 15 makes the planner choose the nested-loop
plan (at least the date range I tried).
I thought that the point of effective cache size was to tell the planner
high likely it is for a random page to be in cache. With 200GB of data
for this query and an effective cache size of 3.5 GB I would have
expected that to be accounted for.
>
> Regards,
> Ken
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | ktm@rice.edu | 2013-04-10 17:49:52 | Re: slow bitmap heap scans on pg 9.2 |
Previous Message | ktm@rice.edu | 2013-04-10 13:56:57 | Re: slow bitmap heap scans on pg 9.2 |