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 internal
    partition bounds, constraint exclusion may be able
    to elide additional partitions from the query plan.
   </para>

   <para>
    The default (and recommended) setting of
    <xref linkend="guc-constraint-exclusion"/> is neither
    <literal>on</literal> nor <literal>off</literal>, but an intermediate setting
    called <literal>partition</literal>, which causes the technique to be
    applied only to queries that are likely to be working on inheritance partitioned
    tables.  The <literal>on</literal> setting causes the planner to examine
    <literal>CHECK</literal> constraints in all queries, even simple ones that
    are unlikely to benefit.
   </para>

   <para>
    The following caveats apply to constraint exclusion:

   <itemizedlist>
    <listitem>
     <para>
      Constraint exclusion is only applied during query planning, unlike
      partition pruning, which can also be applied during query execution.
     </para>
    </listitem>

    <listitem>
     <para>
      Constraint exclusion only works when the query's <literal>WHERE</literal>
      clause contains constants (or externally supplied parameters).
      For example, a comparison against a non-immutable function such as
      <function>CURRENT_TIMESTAMP</function> cannot be optimized, since the
      planner cannot know which child table the function's value might fall
      into at run time.
     </para>
    </listitem>

    <listitem>
     <para>
      Keep the partitioning constraints simple, else the planner may not be
      able to prove that child tables might not need to be visited.  Use simple
      equality conditions for list partitioning, or simple
      range tests for range partitioning, as illustrated in the preceding
      examples.  A good rule of thumb is that partitioning constraints should
      contain only comparisons of the partitioning column(s) to constants
      using B-tree-indexable operators, because only B-tree-indexable
      column(s) are allowed in the partition key.
     </para>
    </listitem>

    <listitem>
     <para>
      All constraints on all children of the parent table are examined
      during constraint exclusion, so large numbers of children are likely
      to increase query planning time considerably.  So the legacy
      inheritance based partitioning will work well with up to perhaps a
      hundred child tables; don't try to use many thousands of children.
     </para>
    </listitem>

   </itemizedlist>
   </para>
  </sect2>

  <sect2 id="ddl-partitioning-declarative-best-practices">
   <title>Best Practices for Declarative Partitioning</title>

   <para>
    The choice of how to partition a table should be made carefully, as the
    performance of query planning and execution can be negatively affected by
    poor design.
   </para>

   <para>
    One of the most critical design decisions will be the column or columns
    by which you partition your data.  Often the best choice will be to
    partition by the