compilation may be used by
        <productname>PostgreSQL</productname>, if available (see <xref
        linkend="jit"/>).
        The default is <literal>on</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-join-collapse-limit" xreflabel="join_collapse_limit">
      <term><varname>join_collapse_limit</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>join_collapse_limit</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        The planner will rewrite explicit <literal>JOIN</literal>
        constructs (except <literal>FULL JOIN</literal>s) into lists of
        <literal>FROM</literal> items whenever a list of no more than this many items
        would result.  Smaller values reduce planning time but might
        yield inferior query plans.
       </para>

       <para>
        By default, this variable is set the same as
        <varname>from_collapse_limit</varname>, which is appropriate
        for most uses. Setting it to 1 prevents any reordering of
        explicit <literal>JOIN</literal>s. Thus, the explicit join order
        specified in the query will be the actual order in which the
        relations are joined. Because the query planner does not always choose
        the optimal join order, advanced users can elect to
        temporarily set this variable to 1, and then specify the join
        order they desire explicitly.
        For more information see <xref linkend="explicit-joins"/>.
       </para>

       <para>
        Setting this value to <xref linkend="guc-geqo-threshold"/> or more
        may trigger use of the GEQO planner, resulting in non-optimal
        plans.  See <xref linkend="runtime-config-query-geqo"/>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-plan-cache-mode" xreflabel="plan_cache_mode">
      <term><varname>plan_cache_mode</varname> (<type>enum</type>)
      <indexterm>
       <primary><varname>plan_cache_mode</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Prepared statements (either explicitly prepared or implicitly
        generated, for example by PL/pgSQL) can be executed using custom or
        generic plans.  Custom plans are made afresh for each execution
        using its specific set of parameter values, while generic plans do
        not rely on the parameter values and can be re-used across
        executions.  Thus, use of a generic plan saves planning time, but if
        the ideal plan depends strongly on the parameter values then a
        generic plan may be inefficient.  The choice between these options
        is normally made automatically, but it can be overridden
        with <varname>plan_cache_mode</varname>.
        The allowed values are <literal>auto</literal> (the default),
        <literal>force_custom_plan</literal> and
        <literal>force_generic_plan</literal>.
        This setting is considered when a cached plan is to be executed,
        not when it is prepared.
        For more information see <xref linkend="sql-prepare"/>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-recursive-worktable-factor" xreflabel="recursive_worktable_factor">
      <term><varname>recursive_worktable_factor</varname> (<type>floating point</type>)
      <indexterm>
       <primary><varname>recursive_worktable_factor</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the planner's estimate of the average size of the working
        table of a <link linkend="queries-with-recursive">recursive
        query</link>, as a multiple of the estimated size of the initial
        non-recursive term of the query.  This helps the planner choose
        the most appropriate method for joining the working table to the
        query's other tables.