Index: doc/src/sgml/wal.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v
retrieving revision 1.58
diff -c -c -r1.58 wal.sgml
*** doc/src/sgml/wal.sgml	15 Jan 2009 00:34:25 -0000	1.58
--- doc/src/sgml/wal.sgml	9 Apr 2009 16:19:18 -0000
***************
*** 326,343 ****
     are points in the sequence of transactions at which it is guaranteed
     that the data files have been updated with all information written before
     the checkpoint.  At checkpoint time, all dirty data pages are flushed to
!    disk and a special checkpoint record is written to the log file.
     In the event of a crash, the crash recovery procedure looks at the latest
     checkpoint record to determine the point in the log (known as the redo
     record) from which it should start the REDO operation.  Any changes made to
!    data files before that point are known to be already on disk.  Hence, after
!    a checkpoint has been made, any log segments preceding the one containing
     the redo record are no longer needed and can be recycled or removed. (When
     <acronym>WAL</acronym> archiving is being done, the log segments must be
     archived before being recycled or removed.)
    </para>
  
    <para>
     The server's background writer process will automatically perform
     a checkpoint every so often.  A checkpoint is created every <xref
     linkend="guc-checkpoint-segments"> log segments, or every <xref
--- 326,352 ----
     are points in the sequence of transactions at which it is guaranteed
     that the data files have been updated with all information written before
     the checkpoint.  At checkpoint time, all dirty data pages are flushed to
!    disk and a special checkpoint record is written to the log file. 
!    (The changes were previously flushed to the <acronym>WAL</acronym> files.)
     In the event of a crash, the crash recovery procedure looks at the latest
     checkpoint record to determine the point in the log (known as the redo
     record) from which it should start the REDO operation.  Any changes made to
!    data files before that point are guaranteed to be already on disk.  Hence, after
!    a checkpoint, log segments preceding the one containing
     the redo record are no longer needed and can be recycled or removed. (When
     <acronym>WAL</acronym> archiving is being done, the log segments must be
     archived before being recycled or removed.)
    </para>
  
    <para>
+    The checkpoint requirement of flushing all dirty data pages to disk
+    can cause a significant I/O load.  For this reason, checkpoint
+    activity is throttled so I/O begins at checkpoint start and completes
+    before the next checkpoint starts;  this minimizes performance
+    degradation during checkpoints.
+   </para>
+ 
+   <para>
     The server's background writer process will automatically perform
     a checkpoint every so often.  A checkpoint is created every <xref
     linkend="guc-checkpoint-segments"> log segments, or every <xref