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</varname> 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</varname>
         buffers will be written per round.)
         Thus, a setting of 1.0 represents a <quote>just in time</quote> policy
         of writing exactly the number of buffers predicted to be needed.
         Larger values provide some cushion against spikes in demand,
         while smaller values intentionally leave writes to be done by
         server processes.
         The default is 2.0.
         This parameter can only be set in the <filename>postgresql.conf</filename>
         file or on the server command line.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-bgwriter-flush-after" xreflabel="bgwriter_flush_after">
       <term><varname>bgwriter_flush_after</varname> (<type>integer</type>)
       <indexterm>
        <primary><varname>bgwriter_flush_after</varname> configuration parameter</primary>
       </indexterm>
       </term>
       <listitem>
        <para>
         Whenever more than this amount of data has
         been written by the background writer, attempt to force the OS to issue these
         writes to the underlying storage.  Doing so will limit the amount of
         dirty data in the kernel's page cache, reducing the likelihood of
         stalls when an <function>fsync</function> is issued at the end of a checkpoint, or when
         the OS writes data back in larger batches in the background.  Often
         that will result in greatly reduced transaction latency, but there
         also are some cases, especially with workloads that are bigger than
         <xref linkend="guc-shared-buffers"/>, but smaller than the OS's page
         cache, where performance might degrade.  This setting may have no
         effect on some platforms.
         If this value is specified without units, it is taken as blocks,
         that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
         The valid range is between
         <literal>0</literal>, which disables forced writeback, and
         <literal>2MB</literal>.  The default is <literal>512kB</literal> on Linux,
         <literal>0</literal> elsewhere.  (If <symbol>BLCKSZ</symbol> is not 8kB,
         the default and maximum values scale proportionally to it.)
         This parameter can only be set in the <filename>postgresql.conf</filename>
         file or on the server command line.
        </para>
       </listitem>
      </varlistentry>
     </variablelist>

     <para>
      Smaller values of <varname>bgwriter_lru_maxpages</varname> and
      <varname>bgwriter_lru_multiplier</varname> reduce the extra I/O load
      caused by the background writer, but make it more likely that server
      processes will have to issue writes for themselves, delaying interactive
      queries.
     </para>
    </sect2>

    <sect2 id="runtime-config-resource-io">
     <title>I/O</title>

     <variablelist>
      <varlistentry id="guc-backend-flush-after" xreflabel="backend_flush_after">
       <term><varname>backend_flush_after</varname> (<type>integer</type>)
       <indexterm>
        <primary><varname>backend_flush_after</varname> configuration parameter</primary>
       </indexterm>
       </term>
       <listitem>
        <para>
         Whenever more than this amount of data has
         been written by a single backend, attempt to force the OS to issue
         these writes to the underlying storage.  Doing so will limit the
         amount of dirty data in the kernel's page cache, reducing the
         likelihood