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:

Reply via email to