On Sat, May 12, 2007 at 03:28:45PM +0100, Heikki Linnakangas wrote: > >In the case of it being disk-block based, my > >inclination would be to let the kernel do the buffering. In the case of > >the cache being table-row-based, I would expect it to be much more > >space-efficient and I would be inclined to give the memory to the pg. > >In that case, is it feasible to set shared_buffers to something like > >500000 x 8k blocks? We make extensive use of indexes on the larger > >tables and would seldom, if ever, do sequential scans. > > A common rule of thumb people quote here is to set shared_buffers to 1/4 > of available RAM, and leave the rest for OS cache. That's probably a > good configuration to start with.
If you really care about performance it would be a good idea to start with that and do your own benchmarking. Much of the consensus about shared_buffers was built up before 8.0, and the shared buffer management we have today looks nothing like what was in 7.4. You might find that shared_buffers = 50% of memory or even higher might perform better for your workload. If you do find results like that, please share them. :) -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
