1- <!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.46 2005/11/01 23:19:05 neilc Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.47 2005/11/03 00:51:43 neilc Exp $ -->
22
33<chapter id="ddl">
44 <title>Data Definition</title>
@@ -1406,32 +1406,42 @@ SELECT * from cities*;
14061406 </listitem>
14071407 </itemizedlist>
14081408
1409- The benefits will normally be worthwhile only when a data table would
1410- otherwise be very large. That is for you to judge, though would not
1411- usually be lower than the size of physical RAM on the database server.
1409+ The benefits will normally be worthwhile only when a table would
1410+ otherwise be very large. The exact point at which a table will
1411+ benefit from partitioning depends on the application, although the
1412+ size of the table should usually exceed the physical memory of the
1413+ database server.
14121414 </para>
14131415
14141416 <para>
1415- In <productname>PostgreSQL</productname> &version;, the following
1416- partitioning types are supported :
1417+ The following partitioning types are supported by
1418+ <productname>PostgreSQL</productname> &version; :
14171419
1418- <itemizedlist>
1419- <listitem>
1420- <para>
1421- "Range Partitioning" where the table is partitioned along a
1422- "range" defined by a single column or set of columns, with no
1423- overlap between partitions. Examples might be a date range or a
1424- range of identifiers for particular business objects.
1425- </para>
1426- </listitem>
1420+ <variablelist>
1421+ <varlistentry>
1422+ <term>Range Partitioning</term>
14271423
1428- <listitem>
1429- <para>
1430- "List Partitioning" where the table is partitioned by
1431- explicitly listing which values relate to each partition.
1432- </para>
1433- </listitem>
1434- </itemizedlist>
1424+ <listitem>
1425+ <para>
1426+ The table is partitioned along a <quote>range</quote> defined
1427+ by a single column or set of columns, with no overlap between
1428+ partitions. Examples might be a date range or a range of
1429+ identifiers for particular business objects.
1430+ </para>
1431+ </listitem>
1432+ </varlistentry>
1433+
1434+ <varlistentry>
1435+ <term>List Partitioning</term>
1436+
1437+ <listitem>
1438+ <para>
1439+ The table is partitioned by explicitly listing which values
1440+ relate to each partition.
1441+ </para>
1442+ </listitem>
1443+ </varlistentry>
1444+ </variablelist>
14351445
14361446 Hash partitioning is not currently supported.
14371447 </para>
@@ -1471,8 +1481,7 @@ SELECT * from cities*;
14711481
14721482 <para>
14731483 We will refer to the child tables as partitions, though they
1474- are in every way just normal <productname>PostgreSQL</>
1475- tables.
1484+ are in every way normal <productname>PostgreSQL</> tables.
14761485 </para>
14771486 </listitem>
14781487
@@ -1485,15 +1494,16 @@ SELECT * from cities*;
14851494 for constraint exclusion. Simple examples would be:
14861495<programlisting>
14871496CHECK ( x = 1 )
1488- CHECK ( county IN ('Oxfordshire','Buckinghamshire','Warwickshire'))
1497+ CHECK ( county IN (
14891498CHECK ( outletID BETWEEN 1 AND 99 )
14901499</programlisting>
14911500
1492- These can be linked together with boolean operators AND and OR to
1493- form complex constraints. Note that there is no difference in syntax
1494- between Range and List Partitioning mechanisms; those terms are
1495- descriptive only. Ensure that the set of values in each child table
1496- do not overlap.
1501+ These can be linked together with the boolean operators
1502+ <literal>AND</literal> and <literal>OR</literal> to form
1503+ complex constraints. Note that there is no difference in
1504+ syntax between range and list partitioning; those terms are
1505+ descriptive only. Ensure that the set of values in each child
1506+ table do not overlap.
14971507 </para>
14981508 </listitem>
14991509
@@ -1712,19 +1722,22 @@ DO INSTEAD
17121722
17131723 <listitem>
17141724 <para>
1715- For some datatypes you must explicitly coerce the constant values
1716- into the datatype of the column. The following constraint will
1717- work if x is an INTEGER datatype, but not if x is BIGINT datatype.
1725+ For some datatypes you must explicitly coerce the constant
1726+ values into the datatype of the column. The following constraint
1727+ will work if <varname>x</varname> is an <type>integer</type>
1728+ datatype, but not if <varname>x</varname> is a
1729+ <type>bigint</type>:
17181730<programlisting>
17191731CHECK ( x = 1 )
17201732</programlisting>
1721- ForBIGINT we must use a constraint like:
1733+ For<type>bigint</type> we must use a constraint like:
17221734<programlisting>
17231735CHECK ( x = 1::bigint )
17241736</programlisting>
1725- The issue is not restricted to BIGINT datatypes but can occur whenever
1726- the default datatype of the constant does not match the datatype of
1727- the column to which it is being compared.
1737+ The problem is not limited to the <type>bigint</type> datatype
1738+ — it can occur whenever the default datatype of the
1739+ constant does not match the datatype of the column to which it
1740+ is being compared.
17281741 </para>
17291742 </listitem>
17301743
@@ -2312,8 +2325,8 @@ REVOKE ALL ON accounts FROM PUBLIC;
23122325 </indexterm>
23132326
23142327 <para>
2315- To create a schema, use the command <literal >CREATE
2316- SCHEMA</literal >. Give the schema a name of your choice. For
2328+ To create a schema, use the command <command >CREATE
2329+ SCHEMA</command >. Give the schema a name of your choice. For
23172330 example:
23182331<programlisting>
23192332CREATE SCHEMA myschema;
