public inbox for [email protected]  

help / color / mirror / Atom feed

From: Greg Smith <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: [email protected]
Cc: Hackers <[email protected]>
Subject: Re: [HACKERS] bgwriter_lru_multiplier blurbs inconsistent
Date: Sun, 20 Jan 2008 15:55:54 -0500 (EST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

On Sun, 20 Jan 2008, Alvaro Herrera wrote:

> Is the bgwriter_lru_multiplier parameter a limit on the number to scan
> or to write?  GUC and docs seem to contradict one another.

It adjusts the target for how many clean buffers it wants to either find 
or create.  This always increases the number of buffers scanned, and 
that's what the GUC description says.

Since a clean buffer can either be a) a reusable candidate found by 
scanning or b) a buffer that is written, on average it's adjusting up the 
number of writes as well.  But it's not guaranteed to--you could have a 
case where it just found all the buffers it needed and never wrote a 
single one.

>         Unless limited by <varname>bgwriter_lru_maxpages</>, the number
>         of dirty buffers written in each round is determined by reference
>         to the number of new buffers that have been needed by server
>         processes during recent rounds.  This number 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.

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.

--
* Greg Smith [email protected] http://www.gregsmith.com Baltimore, MD

view thread (7+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: [HACKERS] bgwriter_lru_multiplier blurbs inconsistent
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox