variants of <literal>ALTER TABLE</literal>, but
   not <literal>INSERT</literal> or <literal>ALTER TABLE ...
   RENAME</literal>) typically default to including child tables and
   support the <literal>ONLY</literal> notation to exclude them.
   The majority of commands that do database maintenance and tuning
   (e.g., <literal>REINDEX</literal>) only work on individual, physical
   tables and do not support recursing over inheritance hierarchies.
   However, both <literal>VACUUM</literal> and <literal>ANALYZE</literal>
   commands default to including child tables and the <literal>ONLY</literal>
   notation is supported to allow them to be excluded.  The respective
   behavior of each individual command is documented in its reference page
   (<xref linkend="sql-commands"/>).
  </para>

  <para>
   A serious limitation of the inheritance feature is that indexes (including
   unique constraints) and foreign key constraints only apply to single
   tables, not to their inheritance children. This is true on both the
   referencing and referenced sides of a foreign key constraint. Thus,
   in the terms of the above example:

   <itemizedlist>
    <listitem>
     <para>
      If we declared <structname>cities</structname>.<structfield>name</structfield> to be
      <literal>UNIQUE</literal> or a <literal>PRIMARY KEY</literal>, this would not stop the
      <structname>capitals</structname> table from having rows with names duplicating
      rows in <structname>cities</structname>.  And those duplicate rows would by
      default show up in queries from <structname>cities</structname>.  In fact, by
      default <structname>capitals</structname> would have no unique constraint at all,
      and so could contain multiple rows with the same name.
      You could add a unique constraint to <structname>capitals</structname>, but this
      would not prevent duplication compared to <structname>cities</structname>.
     </para>
    </listitem>

    <listitem>
     <para>
      Similarly, if we were to specify that
      <structname>cities</structname>.<structfield>name</structfield> <literal>REFERENCES</literal> some
      other table, this constraint would not automatically propagate to
      <structname>capitals</structname>.  In this case you could work around it by
      manually adding the same <literal>REFERENCES</literal> constraint to
      <structname>capitals</structname>.
     </para>
    </listitem>

    <listitem>
     <para>
      Specifying that another table's column <literal>REFERENCES
      cities(name)</literal> would allow the other table to contain city names, but
      not capital names.  There is no good workaround for this case.
     </para>
    </listitem>
   </itemizedlist>

   Some functionality not implemented for inheritance hierarchies is
   implemented for declarative partitioning.
   Considerable care is needed in deciding whether partitioning with legacy
   inheritance is useful for your application.
  </para>

   </sect2>
  </sect1>

  <sect1 id="ddl-partitioning">
   <title>Table Partitioning</title>

   <indexterm>
    <primary>partitioning</primary>
   </indexterm>

   <indexterm>
    <primary>table</primary>
    <secondary>partitioning</secondary>
   </indexterm>

   <indexterm>
    <primary>partitioned table</primary>
   </indexterm>

   <para>
    <productname>PostgreSQL</productname> supports basic table
    partitioning. This section describes why and how to implement
    partitioning as part of your database design.
   </para>

   <sect2 id="ddl-partitioning-overview">
     <title>Overview</title>

    <para>
     Partitioning refers to splitting what is logically one large table into
     smaller physical pieces.  Partitioning can provide several benefits:
    <itemizedlist>
     <listitem>
      <para>
       Query performance can be improved dramatically in certain situations,
       particularly when most of the heavily accessed rows of the table are in a
       single partition or a small number