From 1e985720ebd1a68ae3c64a660caebf72efca59c7 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 21 Jan 2008 03:28:42 +0000
Subject: [PATCH] Improve description of bgwriter_lru_multiplier, per
discussion.
---
doc/src/sgml/config.sgml | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index e0ad0cf3029..a64dabfd058 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.160 2007/12/11 20:07:31 alvherre Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.161 2008/01/21 03:28:42 tgl Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
@@ -1192,17 +1192,16 @@ SET ENABLE_SEQSCAN TO OFF;
<title>Background Writer</title>
<para>
- Beginning in <productname>PostgreSQL</> 8.0, there is a separate server
+ There is a separate server
process called the <firstterm>background writer</>, whose function
is to issue writes of <quote>dirty</> shared buffers. The intent is
that server processes handling user queries should seldom or never have
to wait for a write to occur, because the background writer will do it.
However there is a net overall
- increase in I/O load, because where a repeatedly-dirtied page might
- before have been written only once per checkpoint interval, the
+ increase in I/O load, because a repeatedly-dirtied page might
+ otherwise be written only once per checkpoint interval, but the
background writer might write it several times in the same interval.
- In most situations a continuous low load is preferable to periodic
- spikes, but the parameters discussed in this subsection can be used to
+ The parameters discussed in this subsection can be used to
tune the behavior for local needs.
</para>
@@ -1253,12 +1252,14 @@ SET ENABLE_SEQSCAN TO OFF;
</indexterm>
<listitem>
<para>
- 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.
+ 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 an 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.)
Thus, a setting of 1.0 represents a <quote>just in time</> policy
of writing exactly the number of buffers predicted to be needed.
Larger values provide some cushion against spikes in demand,
--
GitLab