may be useful to control for this by separately
        setting <xref linkend="guc-autovacuum-work-mem"/>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-autovacuum-work-mem" xreflabel="autovacuum_work_mem">
      <term><varname>autovacuum_work_mem</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>autovacuum_work_mem</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies the maximum amount of memory to be used by each
        autovacuum worker process.
        If this value is specified without units, it is taken as kilobytes.
        It defaults to -1, indicating that
        the value of <xref linkend="guc-maintenance-work-mem"/> should
        be used instead.  The setting has no effect on the behavior of
        <command>VACUUM</command> when run in other contexts.
        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-vacuum-buffer-usage-limit" xreflabel="vacuum_buffer_usage_limit">
      <term>
       <varname>vacuum_buffer_usage_limit</varname> (<type>integer</type>)
       <indexterm>
        <primary><varname>vacuum_buffer_usage_limit</varname> configuration parameter</primary>
       </indexterm>
      </term>
      <listitem>
       <para>
        Specifies the size of the
        <glossterm linkend="glossary-buffer-access-strategy">Buffer Access Strategy</glossterm>
        used by the <command>VACUUM</command> and <command>ANALYZE</command>
        commands.  A setting of <literal>0</literal> will allow the operation
        to use any number of <varname>shared_buffers</varname>.  Otherwise
        valid sizes range from <literal>128 kB</literal> to
        <literal>16 GB</literal>.  If the specified size would exceed 1/8 the
        size of <varname>shared_buffers</varname>, the size is silently capped
        to that value.  The default value is <literal>2MB</literal>.  If
        this value is specified without units, it is taken as kilobytes.  This
        parameter can be set at any time.  It can be overridden for
        <xref linkend="sql-vacuum"/> and <xref linkend="sql-analyze"/>
        when passing the <option>BUFFER_USAGE_LIMIT</option> option.  Higher
        settings can allow <command>VACUUM</command> and
        <command>ANALYZE</command> to run more quickly, but having too large a
        setting may cause too many other useful pages to be evicted from
        shared buffers.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-logical-decoding-work-mem" xreflabel="logical_decoding_work_mem">
      <term><varname>logical_decoding_work_mem</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>logical_decoding_work_mem</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies the maximum amount of memory to be used by logical decoding,
        before some of the decoded changes are written to local disk. This
        limits the amount of memory used by logical streaming replication
        connections. It defaults to 64 megabytes (<literal>64MB</literal>).
        Since each replication connection only uses a single buffer of this size,
        and an installation normally doesn't have many such connections
        concurrently (as limited by <varname>max_wal_senders</varname>), it's
        safe to set this value significantly higher than <varname>work_mem</varname>,
        reducing the amount of decoded changes written to disk.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-commit-timestamp-buffers" xreflabel="commit_timestamp_buffers">
      <term><varname>commit_timestamp_buffers</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>commit_timestamp_buffers</varname>