From: John A Meinel <john@arbash-meinel.com>
To: emil@baymountain.com, Postgresql Performance <pgsql-performance@postgresql.org>
Subject: Re: Planner constants for RAM resident databases
Date: Fri, 01 Jul 2005 22:14:50 -0500
Message-ID: <42C606AA.8060406@arbash-meinel.com> (raw)
In-Reply-To: <200507012311.37942.emil@baymountain.com>
References: <200507012159.39041.emil@baymountain.com>
<42C5FFB9.9050302@arbash-meinel.com>
<200507012311.37942.emil@baymountain.com>
Emil Briggs wrote:
>>I just mentioned random_page_cost, but you should also tune
>>effective_cache_size, since that is effectively most of your RAM. It
>>depends what else is going on in the system, but setting it as high as
>>say 12-14GB is probably reasonable if it is a dedicated machine. With
>>random_page_cost 1.5-2, and higher effective_cache_size, you should be
>>doing pretty well.
>>John
>>=:->
>>
>>
>
>I tried playing around with these and they had no effect. It seems the only
>thing that makes a difference is cpu_tuple_cost.
>
>
>
I'm surprised. I know cpu_tuple_cost can effect it as well, but usually
the recommended way to get indexed scans is the above two parameters.
When you do "explain analyze" of a query that you have difficulties
with, how are the planner's estimates. Are the estimated number of rows
about equal to the actual number of rows?
If the planner is mis-estimating, there is a whole different set of
tuning to do to help it estimate correctly.
John
=:->
PS> Use reply-all so that your comments go to the list.
Attachments:
signature.asc (application/pgp-signature, 252B) download
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: john@arbash-meinel.com
Subject: Re: Planner constants for RAM resident databases
In-Reply-To: <42C606AA.8060406@arbash-meinel.com>
* 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