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. +