Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1

Scott Marlowe wrote:

On 9/10/07, Gregory Stark <stark@enterprisedb.com> wrote: 

"Luke Lonergan" <llonergan@greenplum.com> writes:   

Should be a lot higher, something like 10-15 is approximating accurate.     

Most people's experience is that due to Postgres underestimating the benefits
of caching lowering the random_page_cost is helpful.   

Quite often the real problem is that they have effective_cache_size
too small, and they use random_page_cost to get the planner to switch
to index scans on small tables.  With a large effective_cache_size and
small to moderate table (i.e. it fits in memory pretty handily) the
planner seems much better in the last few major releases about picking
an index over a sequential scan

In my case, I set effective_cache_size to 25% of the RAM available to the system (256 Mbytes), for a database that was about 100 Mbytes or less. I found performance to increase when reducing random_page_cost from 4.0 to 3.0.

For a database that truly fits entirely in memory, I assume random_page_cost is closer to 1.0. The planner should know that there is no significant seek cost for RAM.

I will try to compare results tonight using 8.2. The last time I checked may have been 8.1. I am also curious to see what the current algorithm is with regard to effective_cache_size.

Cheers,
mark

-- 
Mark Mielke <mark@mielke.cc>