involves a join of many tables or requires
   the application of several rules. If the statement is relatively simple
   to plan and rewrite but relatively expensive to execute, the
   performance advantage of prepared statements will be less noticeable.
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

  <variablelist>
   <varlistentry>
    <term><replaceable class="parameter">name</replaceable></term>
    <listitem>
     <para>
      An arbitrary name given to this particular prepared
      statement. It must be unique within a single session and is
      subsequently used to execute or deallocate a previously prepared
      statement.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">data_type</replaceable></term>
    <listitem>
     <para>
      The data type of a parameter to the prepared statement.  If the
      data type of a particular parameter is unspecified or is
      specified as <literal>unknown</literal>, it will be inferred
      from the context in which the parameter is first referenced. To refer to the
      parameters in the prepared statement itself, use
      <literal>$1</literal>, <literal>$2</literal>, etc.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">statement</replaceable></term>
    <listitem>
     <para>
      Any <command>SELECT</command>, <command>INSERT</command>, <command>UPDATE</command>,
      <command>DELETE</command>, <command>MERGE</command>, or <command>VALUES</command>
      statement.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1 id="sql-prepare-notes">
  <title>Notes</title>

  <para>
   A prepared statement can be executed with either a <firstterm>generic
   plan</firstterm> or a <firstterm>custom plan</firstterm>.  A generic
   plan is the same across all executions, while a custom plan is generated
   for a specific execution using the parameter values given in that call.
   Use of a generic plan avoids planning overhead, but in some situations
   a custom plan will be much more efficient to execute because the planner
   can make use of knowledge of the parameter values.  (Of course, if the
   prepared statement has no parameters, then this is moot and a generic
   plan is always used.)
  </para>

  <para>
   By default (that is, when <xref linkend="guc-plan-cache-mode"/> is set
   to <literal>auto</literal>), the server will automatically choose
   whether to use a generic or custom plan for a prepared statement that
   has parameters.  The current rule for this is that the first five
   executions are done with custom plans and the average estimated cost of
   those plans is calculated.  Then a generic plan is created and its
   estimated cost is compared to the average custom-plan cost.  Subsequent
   executions use the generic plan if its cost is not so much higher than
   the average custom-plan cost as to make repeated replanning seem
   preferable.
  </para>

  <para>
   This heuristic can be overridden, forcing the server to use either
   generic or custom plans, by setting <varname>plan_cache_mode</varname>
   to <literal>force_generic_plan</literal>
   or <literal>force_custom_plan</literal> respectively.
   This setting is primarily useful if the generic plan's cost estimate
   is badly off for some reason, allowing it to be chosen even though
   its actual cost is much more than that of a custom plan.
  </para>

  <para>
   To examine the query plan <productname>PostgreSQL</productname> is using
   for a prepared statement, use <link linkend="sql-explain"><command>EXPLAIN</command></link>,