diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 2cd0b8ab9df..02583911540 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -2979,15 +2979,16 @@ VALUES ('Albany', NULL, NULL, 'NY'); Individual partitions are linked to the partitioned table with inheritance behind-the-scenes; however, it is not possible to use some of the - inheritance features discussed in the previous section with partitioned - tables and partitions. For example, a partition cannot have any parents - other than the partitioned table it is a partition of, nor can a regular - table inherit from a partitioned table making the latter its parent. - That means partitioned tables and partitions do not participate in - inheritance with regular tables. Since a partition hierarchy consisting - of the partitioned table and its partitions is still an inheritance - hierarchy, all the normal rules of inheritance apply as described in - with some exceptions, most notably: + generic features of inheritance (discussed below) with declaratively + partitioned tables or their partitions. For example, a partition + cannot have any parents other than the partitioned table it is a + partition of, nor can a regular table inherit from a partitioned table + making the latter its parent. That means partitioned tables and their + partitions do not participate in inheritance with regular tables. + Since a partition hierarchy consisting of the partitioned table and its + partitions is still an inheritance hierarchy, all the normal rules of + inheritance apply as described in with + some exceptions, most notably: @@ -3003,23 +3004,28 @@ VALUES ('Albany', NULL, NULL, 'NY'); Using ONLY to add or drop a constraint on only the - partitioned table is supported when there are no partitions. Once + partitioned table is supported as long as there are no partitions. Once partitions exist, using ONLY will result in an error as adding or dropping constraints on only the partitioned table, when - partitions exist, is not supported. Instead, constraints can be added - or dropped, when they are not present in the parent table, directly on - the partitions. As a partitioned table does not have any data - directly, attempts to use TRUNCATE - ONLY on a partitioned table will always return an - error. + partitions exist, is not supported. Instead, constraints on the + partitions themselves can be added and (if they are not present in the + parent table) dropped. + + + + + + As a partitioned table does not have any data directly, attempts to use + TRUNCATE ONLY on a partitioned + table will always return an error. Partitions cannot have columns that are not present in the parent. It - is neither possible to specify columns when creating partitions with - CREATE TABLE nor is it possible to add columns to + is not possible to specify columns when creating partitions with + CREATE TABLE, nor is it possible to add columns to partitions after-the-fact using ALTER TABLE. Tables may be added as a partition with ALTER TABLE ... ATTACH PARTITION only if their columns exactly match the parent, including any @@ -3044,7 +3050,7 @@ VALUES ('Albany', NULL, NULL, 'NY'); Updating the partition key of a row might cause it to be moved into a - different partition where this row satisfies its partition constraint. + different partition where this row satisfies the partition bounds. @@ -3358,15 +3364,15 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02 While the built-in declarative partitioning is suitable for most common use cases, there are some circumstances where a more flexible approach may be useful. Partitioning can be implemented using table - inheritance, which allows for several features which are not supported + inheritance, which allows for several features not supported by declarative partitioning, such as: - Partitioning enforces a rule that all partitions must have exactly - the same set of columns as the parent, but table inheritance allows - children to have extra columns not present in the parent. + For declarative partitioning, partitions must have exactly the same set + of columns as the partitioned table, whereas with table inheritance, + child tables may have extra columns not present in the parent. @@ -3768,7 +3774,8 @@ ANALYZE measurement; Partition pruning is a query optimization technique - that improves performance for partitioned tables. As an example: + that improves performance for declaratively partitioned tables. + As an example: SET enable_partition_pruning = on; -- the default @@ -3786,12 +3793,11 @@ SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01'; - You can use the EXPLAIN command to show the - difference between a plan whose partitions have been pruned from one - whose partitions haven't, by using the - configuration - parameter. A typical unoptimized plan for this type of table setup - is: + By using the EXPLAIN command and the configuration parameter, it's + possible to show the difference between a plan for which partitions have + been pruned and one for which they have not. A typical unoptimized + plan for this type of table setup is: SET enable_partition_pruning = off; EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01'; @@ -3892,9 +3898,9 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01'; Currently, pruning of partitions during the planning of an UPDATE or DELETE command is implemented using the constraint exclusion method (however, it is - still ruled by the enable_partition_pruning - setting instead of constraint_exclusion) — - see the next section for details and caveats that apply. + controlled by the enable_partition_pruning rather than + constraint_exclusion) — see the following section + for details and caveats that apply. @@ -3927,10 +3933,10 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01'; Constraint exclusion works in a very similar way to partition pruning, except that it uses each table's CHECK constraints — which gives it its name — whereas partition - pruning uses the table's partitioning constraint, which exists only in - the case of declarative partitioning. Another difference is that it - is only applied at plan time; there is no attempt to remove - partitions at execution time. + pruning uses the table's partition bounds, which exists 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. @@ -3959,8 +3965,8 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01'; - Constraint exclusion is only applied during query planning; it is - not applied at execution time like partition pruning does. + Constraint exclusion is only applied during query planning; unlike + partition pruning, it cannot be applied during query execution. @@ -3970,7 +3976,7 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01'; clause contains constants (or externally supplied parameters). For example, a comparison against a non-immutable function such as CURRENT_TIMESTAMP cannot be optimized, since the - planner cannot know which partition the function value might fall + planner cannot know which partition the function's value might fall into at run time.