Re: random_page_cost vs seq_page_cost

On Tue, Feb 07, 2012 at 07:58:28PM -0500, Bruce Momjian wrote:
> I was initially concerned that tuning advice in this part of the docs
> would look out of place, but now see the 25% shared_buffers
> recommentation, and it looks fine, so we are OK.  (Should we caution
> against more than 8GB of shared buffers?  I don't see that in the docs.)
> 
> I agree we are overdue for better a explanation of random page cost, so
> I agree with your direction.  I did a little word-smithing to tighten up
> your text;  feel free to discard what you don't like:
> 
>     Random access to mechanical disk storage is normally much more expensive
>     than four-times sequential access.  However, a lower default is used
>     (4.0) because the majority of random accesses to disk, such as indexed
>     reads, are assumed to be in cache.  The default value can be thought of
>     as modeling random access as 40 times slower than sequential, while
>     expecting 90% of random reads to be cached.
>     
>     If you believe a 90% cache rate is an incorrect assumption
>     for your workload, you can increase random_page_cost to better
>     reflect the true cost of random storage reads. Correspondingly,
>     if your data is likely to be completely in cache, such as when
>     the database is smaller than the total server memory, decreasing
>     random_page_cost can be appropriate.  Storage that has a low random
>     read cost relative to sequential, e.g. solid-state drives, might
>     also be better modeled with a lower value for random_page_cost.

Patch applied for random_page_cost docs.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +