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 column or set of columns which most commonly appear in
    <literal>WHERE</literal> clauses of queries being executed on the
    partitioned table.  <literal>WHERE</literal> clauses that are compatible
    with the partition bound constraints can be used to prune unneeded
    partitions.  However, you may be forced into making other decisions by
    requirements for the <literal>PRIMARY KEY</literal> or a
    <literal>UNIQUE</literal> constraint.  Removal of unwanted data is also a
    factor to consider when planning your partitioning strategy.  An entire
    partition can be detached fairly quickly, so it may be beneficial to
    design the partition strategy in such a way that all data to be removed
    at once is located in a single partition.
   </para>

   <para>
    Choosing the target number of partitions that the table should be divided
    into is also a critical decision to make.  Not having enough partitions
    may mean that indexes remain too large and that data locality remains poor
    which could result in low cache hit ratios.  However, dividing the table
    into too many partitions can also cause issues.  Too many partitions can
    mean longer query planning times and higher memory consumption during both
    query planning and execution, as further described below.
    When choosing how to partition your table,
    it's also important to consider what changes may occur in the future.  For
    example, if you choose to have one partition per customer and you
    currently have a small number of large customers, consider the
    implications if in several years you instead find yourself with a large
    number of small customers.  In this case, it may be better to choose to
    partition by <literal>HASH</literal> and choose a reasonable number of
    partitions rather than trying to partition by <literal>LIST</literal> and
    hoping that the number of customers does not increase beyond what it is
    practical to partition the data by.
   </para>

   <para>
    Sub-partitioning can be useful to further divide partitions that are
    expected to become larger than other partitions.
    Another option is to use range partitioning with multiple columns in
    the partition key.
    Either of these can easily lead to excessive numbers of partitions,
    so restraint is advisable.
   </para>

   <para>
    It is important to consider the overhead of partitioning during
    query planning and execution.  The query planner is generally able to
    handle partition hierarchies with up to a few thousand partitions fairly
    well, provided that typical queries allow the query planner to prune all
    but a small number of partitions.  Planning times become longer and memory
    consumption becomes higher when more partitions remain after the planner
    performs partition pruning.  Another
    reason to be concerned about having a large number of partitions is that
    the server's memory consumption may grow significantly over