On Mon, Mar 2, 2009 at 7:40 AM, Gauthier, Dave <dave.gauthier@xxxxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
