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
