clauses contain expressions
    whose values are not known at query planning time, for example,
    parameters defined in a <command>PREPARE</command> statement, using a
    value obtained from a subquery, or using a parameterized value on the
    inner side of a nested loop join.  Partition pruning during execution
    can be performed at any of the following times:

    <itemizedlist>
     <listitem>
      <para>
       During initialization of the query plan.  Partition pruning can be
       performed here for parameter values which are known during the
       initialization phase of execution.  Partitions which are pruned
       during this stage will not show up in the query's
       <command>EXPLAIN</command> or <command>EXPLAIN ANALYZE</command>.
       It is possible to determine the number of partitions which were
       removed during this phase by observing the
       <quote>Subplans Removed</quote> property in the
       <command>EXPLAIN</command> output.  The query planner obtains locks for
       all partitions which are part of the plan.  However, when the executor
       uses a cached plan, locks are only obtained on the partitions which
       remain after partition pruning done during the initialization phase of
       execution, i.e., the ones shown in the <command>EXPLAIN</command>
       output and not the ones referred to by the
       <quote>Subplans Removed</quote> property.
      </para>
     </listitem>

     <listitem>
      <para>
       During actual execution of the query plan.  Partition pruning may
       also be performed here to remove partitions using values which are
       only known during actual query execution.  This includes values
       from subqueries and values from execution-time parameters such as
       those from parameterized nested loop joins.  Since the value of
       these parameters may change many times during the execution of the
       query, partition pruning is performed whenever one of the
       execution parameters being used by partition pruning changes.
       Determining if partitions were pruned during this phase requires
       careful inspection of the <literal>loops</literal> property in
       the <command>EXPLAIN ANALYZE</command> output.  Subplans
       corresponding to different partitions may have different values
       for it depending on how many times each of them was pruned during
       execution.  Some may be shown as <literal>(never executed)</literal>
       if they were pruned every time.
      </para>
     </listitem>
    </itemizedlist>
   </para>

   <para>
    Partition pruning can be disabled using the
    <xref linkend="guc-enable-partition-pruning"/> setting.
   </para>
  </sect2>

  <sect2 id="ddl-partitioning-constraint-exclusion">
   <title>Partitioning and Constraint Exclusion</title>

   <indexterm>
    <primary>constraint exclusion</primary>
   </indexterm>

   <para>
    <firstterm>Constraint exclusion</firstterm> is a query optimization
    technique similar to partition pruning.  While it is primarily used
    for partitioning implemented using the legacy inheritance method, it can be
    used for other purposes, including with declarative partitioning.
   </para>

   <para>
    Constraint exclusion works in a very similar way to partition
    pruning, except that it uses each table's <literal>CHECK</literal>
    constraints &mdash; which gives it its name &mdash; whereas partition
    pruning uses the table's partition bounds, which exist only in the
    case of declarative partitioning.  Another difference is that
    constraint exclusion is only applied at plan time; there is no attempt
    to remove partitions at execution time.
   </para>

   <para>
    The fact that constraint exclusion uses <literal>CHECK</literal>
    constraints, which makes it slow compared to partition pruning, can
    sometimes be used as an advantage: because constraints can be defined
    even on declaratively-partitioned tables, in addition to their