From: Steve Singer <ssinger@ca.afilias.info>
To: ktm@rice.edu <ktm@rice.edu>
Cc: pgsql-performance@postgresql.org
Subject: Re: slow bitmap heap scans on pg 9.2
Date: Wed, 10 Apr 2013 11:56:32 -0400
Message-ID: <51658BB0.4000808@ca.afilias.info> (raw)
In-Reply-To: <20130410135657.GY32580@aart.rice.edu>
References: <51656E03.7000701@ca.afilias.info>
<20130410135657.GY32580@aart.rice.edu>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 13-04-10 09:56 AM, ktm@rice.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
>
>
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ssinger@ca.afilias.info, ktm@rice.edu
Subject: Re: slow bitmap heap scans on pg 9.2
In-Reply-To: <51658BB0.4000808@ca.afilias.info>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox