Improve description of bgwriter_lru_multiplier, per discussion.

doc/src/sgml/config.sgml

-<!-- $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,