server's checkpointer process automatically performs
   a checkpoint every so often.  A checkpoint is begun every <xref
   linkend="guc-checkpoint-timeout"/> seconds, or if
   <xref linkend="guc-max-wal-size"/> is about to be exceeded,
   whichever comes first.
   The default settings are 5 minutes and 1 GB, respectively.
   If no WAL has been written since the previous checkpoint, new checkpoints
   will be skipped even if <varname>checkpoint_timeout</varname> has passed.
   (If WAL archiving is being used and you want to put a lower limit on how
   often files are archived in order to bound potential data loss, you should
   adjust the <xref linkend="guc-archive-timeout"/> parameter rather than the
   checkpoint parameters.)
   It is also possible to force a checkpoint by using the SQL
   command <command>CHECKPOINT</command>.
  </para>

  <para>
   Reducing <varname>checkpoint_timeout</varname> and/or
   <varname>max_wal_size</varname> causes checkpoints to occur
   more often. This allows faster after-crash recovery, since less work
   will need to be redone. However, one must balance this against the
   increased cost of flushing dirty data pages more often. If
   <xref linkend="guc-full-page-writes"/> is set (as is the default), there is
   another factor to consider. To ensure data page consistency,
   the first modification of a data page after each checkpoint results in
   logging the entire page content. In that case,
   a smaller checkpoint interval increases the volume of output to the WAL,
   partially negating the goal of using a smaller interval,
   and in any case causing more disk I/O.
  </para>

  <para>
   Checkpoints are fairly expensive, first because they require writing
   out all currently dirty buffers, and second because they result in
   extra subsequent WAL traffic as discussed above.  It is therefore
   wise to set the checkpointing parameters high enough so that checkpoints
   don't happen too often.  As a simple sanity check on your checkpointing
   parameters, you can set the <xref linkend="guc-checkpoint-warning"/>
   parameter.  If checkpoints happen closer together than
   <varname>checkpoint_warning</varname> seconds,
   a message will be output to the server log recommending increasing
   <varname>max_wal_size</varname>.  Occasional appearance of such
   a message is not cause for alarm, but if it appears often then the
   checkpoint control parameters should be increased. Bulk operations such
   as large <command>COPY</command> transfers might cause a number of such warnings
   to appear if you have not set <varname>max_wal_size</varname> high
   enough.
  </para>

  <para>
   To avoid flooding the I/O system with a burst of page writes,
   writing dirty buffers during a checkpoint is spread over a period of time.
   That period is controlled by
   <xref linkend="guc-checkpoint-completion-target"/>, which is
   given as a fraction of the checkpoint interval (configured by using
   <varname>checkpoint_timeout</varname>).
   The I/O rate is adjusted so that the checkpoint finishes when the
   given fraction of
   <varname>checkpoint_timeout</varname> seconds have elapsed, or before
   <varname>max_wal_size</varname> is exceeded, whichever is sooner.
   With the default value of 0.9,
   <productname>PostgreSQL</productname> can be expected to complete each checkpoint
   a bit before the next scheduled checkpoint (at around 90% of the last checkpoint's
   duration).  This spreads out the I/O as much as possible so that the checkpoint
   I/O load is consistent throughout the checkpoint interval.  The disadvantage of
   this is that prolonging checkpoints affects recovery time, because more WAL
   segments will need to be kept around for possible use in recovery.  A user
   concerned about the amount of time required to recover might wish to reduce
   <varname>checkpoint_timeout</varname> so that checkpoints occur more frequently
   but still spread the I/O across the checkpoint interval.  Alternatively,