Bruno Wolff III <bruno@wolff.to> writes:
> Should I leave postgres tuning alone and let Linux use all of the memory
> for buffer caching?
You shouldn't try to make Postgres consume *all* of memory for buffers;
for one thing, if the shmem region is too large then (at least on some
Unixen, not sure about Linux) the kernel might decide to swap out parts
of it. That'd be counterproductive. However:
> Is there any good reason to increase the number of buffers per backend over
> the default of 2?
Yes. Particularly so under 7.1 --- WAL likes to have a lot of buffers
so that it doesn't have to write data to data files too often. I'd
recommend perhaps a few thousand buffers depending on how much RAM you
have (maybe 10-20% of your physical RAM would be a reasonable upper
limit on how much space for buffers).
> Why I am not seeing consitant wall clock times for queries? Presumably
> there is some caching going on, but I am not sure if it is in postgres
> or in the OS.
Both: we have our buffer area, and then the kernel has its own buffers.
We can make good use of kernel-level buffering as well as our shared-memory
buffers, so there's no reason to try to starve the kernel of buffer space.
regards, tom lane