Date: Sat, 12 May 2007 11:55:41 -0500
From: "Jim C. Nasby" <jim@nasby.net>
To: Heikki Linnakangas <heikki@enterprisedb.com>
Cc: Michael van Rooyen <mvanr@bigfoot.com>,
	pgsql-performance@postgresql.org
Subject: Re: Kernel cache vs shared_buffers
Message-ID: <20070512165540.GD52939@nasby.net>
References: <00b301c79486$1c54da80$0200a8c0@saturn>
	<4645CF1D.1030309@enterprisedb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4645CF1D.1030309@enterprisedb.com>
User-Agent: Mutt/1.5.13 (2006-08-11)

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                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)