xreflabel="max_prepared_transactions">
      <term><varname>max_prepared_transactions</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>max_prepared_transactions</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the maximum number of transactions that can be in the
        <quote>prepared</quote> state simultaneously (see <xref
        linkend="sql-prepare-transaction"/>).
        Setting this parameter to zero (which is the default)
        disables the prepared-transaction feature.
        This parameter can only be set at server start.
       </para>

       <para>
        If you are not planning to use prepared transactions, this parameter
        should be set to zero to prevent accidental creation of prepared
        transactions.  If you are using prepared transactions, you will
        probably want <varname>max_prepared_transactions</varname> to be at
        least as large as <xref linkend="guc-max-connections"/>, so that every
        session can have a prepared transaction pending.
       </para>

       <para>
        When running a standby server, you must set this parameter to the
        same or higher value than on the primary server. Otherwise, queries
        will not be allowed in the standby server.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-work-mem" xreflabel="work_mem">
      <term><varname>work_mem</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>work_mem</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the base maximum amount of memory to be used by a query operation
        (such as a sort or hash table) before writing to temporary disk files.
        If this value is specified without units, it is taken as kilobytes.
        The default value is four megabytes (<literal>4MB</literal>).
        Note that a complex query might perform several sort and hash
        operations at the same time, with each operation generally being
        allowed to use as much memory as this value specifies before
        it starts
        to write data into temporary files.  Also, several running
        sessions could be doing such operations concurrently.
        Therefore, the total memory used could be many times the value
        of <varname>work_mem</varname>; it is necessary to keep this
        fact in mind when choosing the value.  Sort operations are used
        for <literal>ORDER BY</literal>, <literal>DISTINCT</literal>,
        and merge joins.
        Hash tables are used in hash joins, hash-based aggregation, memoize
        nodes and hash-based processing of <literal>IN</literal> subqueries.
       </para>
       <para>
        Hash-based operations are generally more sensitive to memory
        availability than equivalent sort-based operations.  The
        memory limit for a hash table is computed by multiplying
        <varname>work_mem</varname> by
        <varname>hash_mem_multiplier</varname>.  This makes it
        possible for hash-based operations to use an amount of memory
        that exceeds the usual <varname>work_mem</varname> base
        amount.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-hash-mem-multiplier" xreflabel="hash_mem_multiplier">
      <term><varname>hash_mem_multiplier</varname> (<type>floating point</type>)
      <indexterm>
       <primary><varname>hash_mem_multiplier</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Used to compute the maximum amount of memory that hash-based
        operations can use.  The final limit is determined by
        multiplying <varname>work_mem</varname> by
        <varname>hash_mem_multiplier</varname>.  The default value is
        2.0, which makes hash-based operations use twice the usual
        <varname>work_mem</varname>