Date: Tue, 15 May 2007 19:08:07 -0500
From: "Jim C. Nasby" <decibel@decibel.org>
To: daveg <daveg@sonic.net>
Cc: Greg Smith <gsmith@gregsmith.com>, pgsql-patches@postgresql.org
Subject: Re: Automatic adjustment of bgwriter_lru_maxpages
Message-ID: <20070516000807.GF20707@nasby.net>
References: <461E108D.6080709@enterprisedb.com>
	<Pine.GSO.4.64.0705121926420.9615@westnet.com>
	<20070514174531.71E0.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
	<Pine.GSO.4.64.0705140926470.9478@westnet.com>
	<9814.1179150750@sss.pgh.pa.us>
	<Pine.GSO.4.64.0705140957360.9478@westnet.com>
	<20070515045516.GE2359@sonic.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070515045516.GE2359@sonic.net>
User-Agent: Mutt/1.5.13 (2006-08-11)

Moving to -performance.

On Mon, May 14, 2007 at 09:55:16PM -0700, daveg wrote:
> Apologies for asking this on the wrong list, but it is at least the right
> thread.
> 
> What is the current thinking on bg_writer setttings for systems such as 
> 4 core Opteron with 16GB or 32GB of memory and heavy batch workloads?

It depends greatly on how much of your data tends to stay 'pinned' in
shared_buffers between checkpoints. In a case where the same data tends
to stay resident you're going to need to depend on the 'all' scan to
decrease the impact of checkpoints (though the load distributed
checkpoint patch will change that greatly).

Other than that tuning bgwriter boils down to your IO capability as well
as how often you're checkpointing.
-- 
Jim Nasby                                      decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)