On Mon, 2005-10-31 at 15:44 +0100, Martijn van Oosterhout wrote: > On Mon, Oct 31, 2005 at 01:34:12PM +0000, Simon Riggs wrote: > > > Secondly, you're assuming that PostgreSQLs caching is at least as > > > efficient as the OS caching, which is more of an assertion than > > > anything else. > > > > Do you doubt that? Why would shared_buffers be variable otherwise? > > Because the optimal hasn't been found and is probably different for > each machine. > > There have been tests that demonstrate that you can raise the buffers > to a certain point which is optimal and after that it just doesn't > help [1]. They peg optimal size at 5-10% of memory. Please read the rest of that thread. Those results and their conclusions were refuted in some detail, which lead to a number of optimizations in 8.0 and 8.1, mostly written by Tom. > Also, as Tom pointed out, any memory assigned to shared buffers can't > be used for sorts, temporary tables, plain old disk caching, trigger > queues or anything else that isn't shared between backends. There are > far more useful uses of memory than just buffering disk blocks. Your point was about cache efficiency as an argument for not increasing shared_buffers. Politely, I don't accept that argument. Clearly, there are some other considerations (for which I agree completely) but those don't prevent you increasing shared_buffers, they just place limits on your overall memory budget which could effect shared_buffers of course. Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match