Received: from localhost (unknown [200.46.204.187])
	by postgresql.org (Postfix) with ESMTP id 37E5E2E0CA6;
	Sun, 20 Jan 2008 18:14:42 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024)
	with ESMTP id 56974-02-3; Sun, 20 Jan 2008 18:14:30 -0400 (AST)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 742E82E346B;
	Sun, 20 Jan 2008 18:05:25 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id m0KM5M98013943;
	Sun, 20 Jan 2008 17:05:22 -0500 (EST)
To: Greg Smith <gsmith@gregsmith.com>
cc: Alvaro Herrera <alvherre@commandprompt.com>, pgsql-docs@postgresql.org,
	Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] bgwriter_lru_multiplier blurbs inconsistent 
In-reply-to: <Pine.GSO.4.64.0801201505250.17332@westnet.com> 
References: <20080120195519.GD22740@alvh.no-ip.org>
	<Pine.GSO.4.64.0801201505250.17332@westnet.com>
Comments: In-reply-to Greg Smith <gsmith@gregsmith.com>
	message dated "Sun, 20 Jan 2008 15:55:54 -0500"
Date: Sun, 20 Jan 2008 17:05:22 -0500
Message-ID: <13942.1200866722@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200801/23
X-Sequence-Number: 4752

Greg Smith <gsmith@gregsmith.com> writes:
> There is nothing incorrect here, it's just not as clear as it could be. 
> Here's a V2 that tries to clear that up:

> Unless limited by <varname>bgwriter_lru_maxpages</>, the number of dirty 
> buffers written in each round is based on the number of new buffers that 
> have been needed by server processes during recent rounds.  The recent 
> need is multiplied by <varname>bgwriter_lru_multiplier</> to arrive at the 
> estimate of the number of buffers that will be needed during the next 
> round.  Buffers are written to meet that need if there aren't enough 
> reusable ones found while scanning.

I think the main problem is the qualifying clause up front in a place
of prominence.  Here's a V3 try:

The number of dirty buffers written in each round is based on the number
of new buffers that have been needed by server processes during recent
rounds.  The average recent need is multiplied by
<varname>bgwriter_lru_multiplier</> to arrive at the estimate of the
number of buffers that will be needed during the next round.  Dirty
buffers are written until there are that many clean, reusable buffers
available.  However, no more than <varname>bgwriter_lru_maxpages</>
buffers will be written per round.

			regards, tom lane