>> Is there any practical limit to the number of shared buffers PG 8.3.7
>> can handle before more becomes counter-productive?
It is more efficient to have the page in shared buffers, rather than doing
a context switch to the OS, copying the entire page from the OS's cache
into shared buffers, and coming back to postgres. Shared buffers use less
CPU. However, this is totally negligible versus the disk wait time of an
uncached IO.
The same page may be cached once in shared_buffers, and once in the OS
cache, so if your shared buffers is half your RAM, and the other half is
disk cache, perhaps it won't be optimal: is stuff is cached twice, you can
cache half as much stuff.
If your entire database can fit in shared buffers, good for you though.
But then a checkpoint comes, and postgres will write all dirty buffers to
disk in the order it finds them in Shared Buffers, which might be totally
different from the on-disk order. If you have enough OS cache left to
absorb these writes, the OS will reorder them. If not, lots of random
writes are going to occur. On a RAID5 this can be a lot of fun.