On Fri, Jun 01, 2018 at 03:00:10PM -0400, Alvaro Herrera wrote:
> On 2018-May-23, Justin Pryzby wrote:
>
> > There's two other, wider changes to consider:
...
>
> > - should we find a unified term for "inheritence-based partitioning" and
> > avoid
> >using the word "partitioning" in that context? For example:
> > "Partitioning
> >can be implemented using table inheritance[...]". One possible phrase
> >currently begin used is: "legacy inheritance method".
>
> Yeah, maybe it'd be a good time to do that. In particular I wondered
> whether the section title "Partitioning and Constraint Exclusion" should
> be changed somehow to note the fact that it's mostly for the legacy
> method.
I made changes to avoid "partition" (which I think should mean a child of
relkind='p', and itself of relkind='r') and "partitioned" (meaning relkind='p'
itself) but left alone most instances of "partitioning".
There's two issues. One is the unfortunately-named, recommended setting of
constraint_exclusion='partition' :(
And one is this, which I think should be disambiguated from native
list/range/hash partition bounds:
Use simple equality conditions for list partitioning, or simple range
tests for range partitioning, as illustrated in the preceding examples.
I'm short on words so maybe someone else can recommend language.
On Fri, Jun 01, 2018 at 02:57:22PM -0400, Alvaro Herrera wrote:
> Pushed. I made a couple of minor changes, in particular I added the
It looks like you also fixed a double negative - thanks.
Justin
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 0258391..d919818 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -3387,8 +3387,8 @@ ALTER TABLE measurement ATTACH PARTITION
measurement_y2008m02
Declarative partitioning only supports range, list and hash
partitioning, whereas table inheritance allows data to be divided in a
manner of the user's choosing. (Note, however, that if constraint
-exclusion is unable to prune partitions effectively, query performance
-will be very poor.)
+exclusion is unable to prune child tables effectively, query
performance
+may be poor.)
@@ -3410,18 +3410,18 @@ ALTER TABLE measurement ATTACH PARTITION
measurement_y2008m02
We use the same measurement table we used
- above. To implement it as a partitioned table using inheritance, use
+ above. To implement partitioning using inheritance, use
the following steps:
Create the master table, from which all of the
- partitions will inherit. This table will contain no data. Do not
+ child tables will inherit. This table will contain no
data. Do not
define any check constraints on this table, unless you intend them
- to be applied equally to all partitions. There is no point in
+ to be applied equally to all child tables. There is no point in
defining any indexes or unique constraints on it, either. For our
- example, master table is the measurement
+ example, the master table is the measurement
table as originally defined.
@@ -3431,7 +3431,7 @@ ALTER TABLE measurement ATTACH PARTITION
measurement_y2008m02
Create several child tables that each inherit from
the master table. Normally, these tables will not add any columns
to the set inherited from the master. Just as with declarative
- partitioning, these partitions are in every way normal
+ partitioning, these tables are in every way normal
PostgreSQL tables (or foreign tables).
@@ -3449,8 +3449,8 @@ CREATE TABLE measurement_y2008m01 () INHERITS
(measurement);
- Add non-overlapping table constraints to the partition tables to
- define the allowed key values in each partition.
+ Add non-overlapping table constraints to the child tables to
+ define the allowed key values in each.
@@ -3461,18 +3461,18 @@ CHECK ( county IN ( 'Oxfordshire', 'Buckinghamshire',
'Warwickshire' ))
CHECK ( outletID = 100 AND outletID 200 )
Ensure that the constraints guarantee that there is no overlap
- between the key values permitted in different partitions. A common
+ between the key values permitted in different child tables. A common
mistake is to set up range constraints like:
CHECK ( outletID BETWEEN 100 AND 200 )
CHECK ( outletID BETWEEN 200 AND 300 )
- This is wrong since it is not clear which partition the key value
- 200 belongs in.
+ This is wrong since it is not clear into which child table the key
+ value 200 belongs.
- It would be better to instead create partitions as follows:
+ It would be better to instead create child
