Re: Planner constants for RAM resident databases

From: John A Meinel <john(at)arbash-meinel(dot)com>
To: emil(at)baymountain(dot)com, Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Planner constants for RAM resident databases
Date: 2005-07-02 03:14:50
Message-ID: 42C606AA.8060406@arbash-meinel.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Madison Kelly 2005-07-02 04:16:55 B-Tree index not being used
Previous Message John A Meinel 2005-07-02 02:40:49 Re: Planner constants for RAM resident databases