Re: DB cache size strategies - Mailing list pgsql-general

From Ed L.
Subject Re: DB cache size strategies
Date
Msg-id 200402102301.22176.pgsql@bluepolka.net
Whole thread Raw
In response to Re: DB cache size strategies  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: DB cache size strategies  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Tuesday February 10 2004 10:26, Tom Lane wrote:
>
> Giving PG half the RAM is counterproductive no matter what --- that
> pretty much guarantees that every page that's in RAM will be in RAM
> twice, once in PG buffers and once in kernel buffers.  The two
> reasonable schools of thought are (1) to make PG buffers relatively
> small and let the kernel do the bulk of the buffering, or (2) to give
> PG most of the RAM and expect it to do the bulk of the buffering.
>
> Past experience has been that theory (1) generally wins.  Jan's recent
> work on ARC buffering may make things more interesting, though.

So, pursuing theory (1) in 'the time before ARC', assuming you have a
dedicated box with little or no non-db competition for resources, why give
PG anymore than is absolutely required (max_connections*2 or 16)?  Why not
just let the kernel reign as completely as possible?  Is that what you mean
by "relatively small"?

TIA.


pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Temporary views
Next
From: Tom Lane
Date:
Subject: Re: DB cache size strategies