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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers