On Mon, 2005-10-31 at 10:58, Simon Riggs wrote:
> 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.
As I understand it, when the last backend referencing a collection of
data stops referencing it, that the buffers holding that data are
released, and if, a second later, another backend wants the data, then
it has to go to the Kernel for it again.
Is this still the case in 8.1?