Re: Shared Buffers

On Mon, Mar 2, 2009 at 7:40 AM, Gauthier, Dave  wrote:
> I believe that op system side buffering can play a role too.  I our case,
> the DB server (machine & op sys) caches data that it pulled from disk (not
> necessarily from a DB) and also the disk servers do the same.  If a block
> was removed from the DB buffer cache to accommodate more recently requested
> data, but the evicted block is live in memory on the DB server or the disk
> server, it can pull from there instead of performing an expensive disk-IO.

This is very true for certain workloads.  If your db is bigger than
memory, and you only work on a tiny bit at a time, the kernel is often
better at caching than pgsql.  Run something like pgbench on a machine
with say 4 Gig of memory and a 40 Gig pgbench db dir, and you're
better off with 128M or something for shared_buffers than 1G often
times.  Truly random small access, has, for me, worked better with
moderate to smaller shared_buffers.  Plus if you need to run a few
memory hog queries, the kernel can flush out some free memory from
cache quickly, but shared_buffers is static.  So, the kernel file
cache is self tuning.

But you'll have to test it with your application to really see.