> The random_page_cost is changed because of an assumption that the
bigger systems
> will be more busy. The more busy a machine is doing I/O the lower the
differential
> between a sequential and random access. ("sequential" to the
application is less
> likely sequential to the physical disk.)
I think this reasoning is valid, but would we then not rather need
something like
a scan_page_cost, that would need to be raised ? Or are the CPU costs so
small,
that only the relation between scan and random counts ?
> I'd like to open a debate about the benefit/cost of shared_buffers.
The question
> is: "Will postgres' management of shared buffers out perform O/S
cache? Is there a
> point of diminishing return on number of buffers? If so, what?
I think the main point for PostgreSQL buffers is to account for "dirty"
pages.
This only because we use OS files and can thus rely on OS file caching.
If your application is update intensive, then you should have sufficient
buffers to hold most dirtied pages between checkpoints. Does that make
sense ?
Andreas