peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);
</programlisting>
      </para>
     </listitem>

     <listitem>
      <para>
       Create partitions.  Each partition's definition must specify bounds
       that correspond to the partitioning method and partition key of the
       parent.  Note that specifying bounds such that the new partition's
       values would overlap with those in one or more existing partitions will
       cause an error.
      </para>

      <para>
       Partitions thus created are in every way normal
       <productname>PostgreSQL</productname>
       tables (or, possibly, foreign tables).  It is possible to specify a
       tablespace and storage parameters for each partition separately.
      </para>

      <para>
       For our example, each partition should hold one month's worth of
       data, to match the requirement of deleting one month's data at a
       time.  So the commands might look like:

<programlisting>
CREATE TABLE measurement_y2006m02 PARTITION OF measurement
    FOR VALUES FROM ('2006-02-01') TO ('2006-03-01');

CREATE TABLE measurement_y2006m03 PARTITION OF measurement
    FOR VALUES FROM ('2006-03-01') TO ('2006-04-01');

...
CREATE TABLE measurement_y2007m11 PARTITION OF measurement
    FOR VALUES FROM ('2007-11-01') TO ('2007-12-01');

CREATE TABLE measurement_y2007m12 PARTITION OF measurement
    FOR VALUES FROM ('2007-12-01') TO ('2008-01-01')
    TABLESPACE fasttablespace;

CREATE TABLE measurement_y2008m01 PARTITION OF measurement
    FOR VALUES FROM ('2008-01-01') TO ('2008-02-01')
    WITH (parallel_workers = 4)
    TABLESPACE fasttablespace;
</programlisting>

       (Recall that adjacent partitions can share a bound value, since
       range upper bounds are treated as exclusive bounds.)
      </para>

      <para>
       If you wish to implement sub-partitioning, again specify the
       <literal>PARTITION BY</literal> clause in the commands used to create
       individual partitions, for example:

<programlisting>
CREATE TABLE measurement_y2006m02 PARTITION OF measurement
    FOR VALUES FROM ('2006-02-01') TO ('2006-03-01')
    PARTITION BY RANGE (peaktemp);
</programlisting>

       After creating partitions of <structname>measurement_y2006m02</structname>,
       any data inserted into <structname>measurement</structname> that is mapped to
       <structname>measurement_y2006m02</structname> (or data that is
       directly inserted into <structname>measurement_y2006m02</structname>,
       which is allowed provided its partition constraint is satisfied)
       will be further redirected to one of its
       partitions based on the <structfield>peaktemp</structfield> column.  The partition
       key specified may overlap with the parent's partition key, although
       care should be taken when specifying the bounds of a sub-partition
       such that the set of data it accepts constitutes a subset of what
       the partition's own bounds allow; the system does not try to check
       whether that's really the case.
      </para>

      <para>
       Inserting data into the parent table that does not map
       to one of the existing partitions will cause an error; an appropriate
       partition must be added manually.
      </para>

      <para>
       It is not necessary to manually create table constraints describing
       the partition boundary conditions for partitions.  Such constraints
       will be created automatically.
      </para>
     </listitem>

     <listitem>
      <para>
       Create an index on the key column(s), as well as any other indexes you
       might want, on the partitioned table. (The key index is not strictly
       necessary, but in most scenarios it is helpful.)
       This automatically creates a matching index on each partition, and
       any partitions you create or attach later will also have such an
       index.
       An index or unique constraint declared on a partitioned table