Specifies how often the WAL writer flushes WAL, in volume terms.
        If the last flush happened less
        than <varname>wal_writer_delay</varname> ago and less
        than <varname>wal_writer_flush_after</varname> worth of WAL has been
        produced since, then WAL is only written to the operating system, not
        flushed to disk.  If <varname>wal_writer_flush_after</varname> is set
        to <literal>0</literal> then WAL data is always flushed immediately.
        If this value is specified without units, it is taken as WAL blocks,
        that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 8kB.
        The default is <literal>1MB</literal>.
        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-wal-skip-threshold" xreflabel="wal_skip_threshold">
      <term><varname>wal_skip_threshold</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>wal_skip_threshold</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        When <varname>wal_level</varname> is <literal>minimal</literal> and a
        transaction commits after creating or rewriting a permanent relation,
        this setting determines how to persist the new data.  If the data is
        smaller than this setting, write it to the WAL log; otherwise, use an
        fsync of affected files.  Depending on the properties of your storage,
        raising or lowering this value might help if such commits are slowing
        concurrent transactions.  If this value is specified without units, it
        is taken as kilobytes.  The default is two megabytes
        (<literal>2MB</literal>).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-commit-delay" xreflabel="commit_delay">
      <term><varname>commit_delay</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>commit_delay</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Setting <varname>commit_delay</varname> adds a time delay
        before a WAL flush is initiated.  This can improve
        group commit throughput by allowing a larger number of transactions
        to commit via a single WAL flush, if system load is high enough
        that additional transactions become ready to commit within the
        given interval.  However, it also increases latency by up to the
        <varname>commit_delay</varname> for each WAL
        flush.  Because the delay is just wasted if no other transactions
        become ready to commit, a delay is only performed if at least
        <varname>commit_siblings</varname> other transactions are active
        when a flush is about to be initiated.  Also, no delays are
        performed if <varname>fsync</varname> is disabled.
        If this value is specified without units, it is taken as microseconds.
        The default <varname>commit_delay</varname> is zero (no delay).
        Only superusers and users with the appropriate <literal>SET</literal>
        privilege can change this setting.
       </para>
       <para>
        In <productname>PostgreSQL</productname> releases prior to 9.3,
        <varname>commit_delay</varname> behaved differently and was much
        less effective: it affected only commits, rather than all WAL flushes,
        and waited for the entire configured delay even if the WAL flush
        was completed sooner.  Beginning in <productname>PostgreSQL</productname> 9.3,
        the first process that becomes ready to flush waits for the configured
        interval, while subsequent processes wait only until the leader
        completes the flush operation.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-commit-siblings" xreflabel="commit_siblings">
      <term><varname>commit_siblings</varname>