@@ -3397,8 +3397,8 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
33973397 Declarative partitioning only supports range, list and hash
33983398 partitioning, whereas table inheritance allows data to be divided in a
33993399 manner of the user's choosing. (Note, however, that if constraint
3400- exclusion is unable to prunepartitions effectively, query performance
3401- will be very poor.)
3400+ exclusion is unable to prunechild tables effectively, query performance
3401+ might be poor.)
34023402 </para>
34033403 </listitem>
34043404
@@ -3420,16 +3420,16 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
34203420
34213421 <para>
34223422 We use the same <structname>measurement</structname> table we used
3423- above. To implementit as a partitioned table using inheritance, use
3423+ above. To implementpartitioning using inheritance, use
34243424 the following steps:
34253425
34263426 <orderedlist spacing="compact">
34273427 <listitem>
34283428 <para>
34293429 Create the <quote>master</quote> table, from which all of the
3430- partitions will inherit. This table will contain no data. Do not
3430+ <quote>child</quote> tables will inherit. This table will contain no data. Do not
34313431 define any check constraints on this table, unless you intend them
3432- to be applied equally to allpartitions . There is no point in
3432+ to be applied equally to allchild tables . There is no point in
34333433 defining any indexes or unique constraints on it, either. For our
34343434 example, the master table is the <structname>measurement</structname>
34353435 table as originally defined.
@@ -3441,7 +3441,7 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
34413441 Create several <quote>child</quote> tables that each inherit from
34423442 the master table. Normally, these tables will not add any columns
34433443 to the set inherited from the master. Just as with declarative
3444- partitioning, thesepartitions are in every way normal
3444+ partitioning, thesetables are in every way normal
34453445 <productname>PostgreSQL</productname> tables (or foreign tables).
34463446 </para>
34473447
@@ -3459,8 +3459,8 @@ CREATE TABLE measurement_y2008m01 () INHERITS (measurement);
34593459
34603460 <listitem>
34613461 <para>
3462- Add non-overlapping table constraints to thepartition tables to
3463- define the allowed key values in each partition .
3462+ Add non-overlapping table constraints to thechild tables to
3463+ define the allowed key values in each.
34643464 </para>
34653465
34663466 <para>
@@ -3471,18 +3471,18 @@ CHECK ( county IN ( 'Oxfordshire', 'Buckinghamshire', 'Warwickshire' ))
34713471CHECK ( outletID >= 100 AND outletID < 200 )
34723472</programlisting>
34733473 Ensure that the constraints guarantee that there is no overlap
3474- between the key values permitted in differentpartitions . A common
3474+ between the key values permitted in differentchild tables . A common
34753475 mistake is to set up range constraints like:
34763476<programlisting>
34773477CHECK ( outletID BETWEEN 100 AND 200 )
34783478CHECK ( outletID BETWEEN 200 AND 300 )
34793479</programlisting>
3480- This is wrong since it is not clear whichpartition the key value
3481- 200 belongs in.
3480+ This is wrong since it is not clear whichchild table the key
3481+ value 200 belongs in.
34823482 </para>
34833483
34843484 <para>
3485- It would be better to instead createpartitions as follows:
3485+ It would be better to instead createchild tables as follows:
34863486
34873487<programlisting>
34883488CREATE TABLE measurement_y2006m02 (
@@ -3511,7 +3511,7 @@ CREATE TABLE measurement_y2008m01 (
35113511
35123512 <listitem>
35133513 <para>
3514- For eachpartition , create an index on the key column(s),
3514+ For eachchild table , create an index on the key column(s),
35153515 as well as any other indexes you might want.
35163516<programlisting>
35173517CREATE INDEX measurement_y2006m02_logdate ON measurement_y2006m02 (logdate);
@@ -3527,9 +3527,9 @@ CREATE INDEX measurement_y2008m01_logdate ON measurement_y2008m01 (logdate);
35273527 <para>
35283528 We want our application to be able to say <literal>INSERT INTO
35293529 measurement ...</literal> and have the data be redirected into the
3530- appropriatepartition table. We can arrange that by attaching
3530+ appropriatechild table. We can arrange that by attaching
35313531 a suitable trigger function to the master table.
3532- If data will be added only to the latestpartition , we can
3532+ If data will be added only to the latestchild , we can
35333533 use a very simple trigger function:
35343534
35353535<programlisting>
@@ -3555,13 +3555,13 @@ CREATE TRIGGER insert_measurement_trigger
35553555</programlisting>
35563556
35573557 We must redefine the trigger function each month so that it always
3558- points to the currentpartition . The trigger definition does
3558+ points to the currentchild table . The trigger definition does
35593559 not need to be updated, however.
35603560 </para>
35613561
35623562 <para>
35633563 We might want to insert data and have the server automatically
3564- locate thepartition into which the row should be added. We
3564+ locate thechild table into which the row should be added. We
35653565 could do this with a more complex trigger function, for example:
35663566
35673567<programlisting>
@@ -3589,7 +3589,7 @@ LANGUAGE plpgsql;
35893589
35903590 The trigger definition is the same as before.
35913591 Note that each <literal>IF</literal> test must exactly match the
3592- <literal>CHECK</literal> constraint for itspartition .
3592+ <literal>CHECK</literal> constraint for itschild table .
35933593 </para>
35943594
35953595 <para>
@@ -3600,16 +3600,16 @@ LANGUAGE plpgsql;
36003600
36013601 <note>
36023602 <para>
3603- In practice it might be best to check the newestpartition first,
3604- if most inserts go into thatpartition . For simplicity we have
3603+ In practice, it might be best to check the newestchild first,
3604+ if most inserts go into thatchild . For simplicity, we have
36053605 shown the trigger's tests in the same order as in other parts
36063606 of this example.
36073607 </para>
36083608 </note>
36093609
36103610 <para>
36113611 A different approach to redirecting inserts into the appropriate
3612- partition table is to set up rules, instead of a trigger, on the
3612+ child table is to set up rules, instead of a trigger, on the
36133613 master table. For example:
36143614
36153615<programlisting>
@@ -3635,7 +3635,7 @@ DO INSTEAD
36353635 <para>
36363636 Be aware that <command>COPY</command> ignores rules. If you want to
36373637 use <command>COPY</command> to insert data, you'll need to copy into the
3638- correctpartition table rather than into the master. <command>COPY</command>
3638+ correctchild table rather than directly into the master. <command>COPY</command>
36393639 does fire triggers, so you can use it normally if you use the trigger
36403640 approach.
36413641 </para>
@@ -3651,33 +3651,33 @@ DO INSTEAD
36513651 <para>
36523652 Ensure that the <xref linkend="guc-constraint-exclusion"/>
36533653 configuration parameter is not disabled in
3654- <filename>postgresql.conf</filename>.
3655- If it is, queries will not beoptimized as desired .
3654+ <filename>postgresql.conf</filename>; otherwise
3655+ child tables may beaccessed unnecessarily .
36563656 </para>
36573657 </listitem>
36583658 </orderedlist>
36593659 </para>
36603660
36613661 <para>
3662- As we can see, a complexpartitioning scheme could require a
3662+ As we can see, a complextable hierarchy could require a
36633663 substantial amount of DDL. In the above example we would be creating
3664- a newpartition each month, so it might be wise to write a script that
3664+ a newchild table each month, so it might be wise to write a script that
36653665 generates the required DDL automatically.
36663666 </para>
36673667 </sect3>
36683668
36693669 <sect3 id="ddl-partitioning-inheritance-maintenance">
3670- <title>Partition Maintenance</title>
3670+ <title>Maintenance for Inheritance Partitioning </title>
36713671 <para>
3672- To remove old data quickly, simply drop thepartition that is no longer
3672+ To remove old data quickly, simply drop thechild table that is no longer
36733673 necessary:
36743674<programlisting>
36753675DROP TABLE measurement_y2006m02;
36763676</programlisting>
36773677 </para>
36783678
36793679 <para>
3680- To remove thepartition from thepartitioned table but retain access to
3680+ To remove thechild table from theinheritance hierarchy table but retain access to
36813681 it as a table in its own right:
36823682
36833683<programlisting>
@@ -3686,18 +3686,19 @@ ALTER TABLE measurement_y2006m02 NO INHERIT measurement;
36863686 </para>
36873687
36883688 <para>
3689- To add a newpartition to handle new data, create an emptypartition
3690- just as the originalpartitions were created above:
3689+ To add a newchild table to handle new data, create an emptychild table
3690+ just as the originalchildren were created above:
36913691
36923692<programlisting>
36933693CREATE TABLE measurement_y2008m02 (
36943694 CHECK ( logdate >= DATE '2008-02-01' AND logdate < DATE '2008-03-01' )
36953695) INHERITS (measurement);
36963696</programlisting>
36973697
3698- Alternatively, one may want to create the new table outside the partition
3699- structure, and make it a partition after the data is loaded, checked,
3700- and transformed.
3698+ Alternatively, one may want to create and populate the new child table
3699+ before adding it to the table hierarchy. This could allow data to be
3700+ loaded, checked, and transformed before being made visible to queries on
3701+ the parent table.
37013702
37023703<programlisting>
37033704CREATE TABLE measurement_y2008m02
@@ -3715,27 +3716,27 @@ ALTER TABLE measurement_y2008m02 INHERIT measurement;
37153716 <title>Caveats</title>
37163717
37173718 <para>
3718- The following caveats apply topartitioned tables implemented using
3719+ The following caveats apply topartitioning implemented using
37193720 inheritance:
37203721 <itemizedlist>
37213722 <listitem>
37223723 <para>
37233724 There is no automatic way to verify that all of the
37243725 <literal>CHECK</literal> constraints are mutually
37253726 exclusive. It is safer to create code that generates
3726- partitions and creates and/or modifies associated objects than
3727+ child tables and creates and/or modifies associated objects than
37273728 to write each by hand.
37283729 </para>
37293730 </listitem>
37303731
37313732 <listitem>
37323733 <para>
3733- The schemes shown here assume that thepartition key column(s)
3734- of a row never change, or at least do not change enough to require
3735- it to move to another partition. An <command>UPDATE</command> that attempts
3734+ The schemes shown here assume that thevalues of a row's key column(s)
3735+ never change, or at least do not change enough to require it to move to another partition.
3736+ An <command>UPDATE</command> that attempts
37363737 to do that will fail because of the <literal>CHECK</literal> constraints.
37373738 If you need to handle such cases, you can put suitable update triggers
3738- on thepartition tables, but it makes management of the structure
3739+ on thechild tables, but it makes management of the structure
37393740 much more complicated.
37403741 </para>
37413742 </listitem>
@@ -3744,7 +3745,7 @@ ALTER TABLE measurement_y2008m02 INHERIT measurement;
37443745 <para>
37453746 If you are using manual <command>VACUUM</command> or
37463747 <command>ANALYZE</command> commands, don't forget that
3747- you need to run them on eachpartition individually. A command like:
3748+ you need to run them on eachchild table individually. A command like:
37483749<programlisting>
37493750ANALYZE measurement;
37503751</programlisting>
@@ -3764,7 +3765,7 @@ ANALYZE measurement;
37643765 <listitem>
37653766 <para>
37663767 Triggers or rules will be needed to route rows to the desired
3767- partition , unless the application is explicitly aware of the
3768+ child table , unless the application is explicitly aware of the
37683769 partitioning scheme. Triggers may be complicated to write, and will
37693770 be much slower than the tuple routing performed internally by
37703771 declarative partitioning.
@@ -3935,7 +3936,7 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
39353936 <para>
39363937 <firstterm>Constraint exclusion</firstterm> is a query optimization
39373938 technique similar to partition pruning. While it is primarily used
3938- forpartitioned tables using the legacy inheritance method, it can be
3939+ forpartitioning implemented using the legacy inheritance method, it can be
39393940 used for other purposes, including with declarative partitioning.
39403941 </para>
39413942
@@ -3953,9 +3954,9 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
39533954 The fact that constraint exclusion uses <literal>CHECK</literal>
39543955 constraints, which makes it slow compared to partition pruning, can
39553956 sometimes be used as an advantage: because constraints can be defined
3956- even on declaratively-partitioned tables, in addition tothe internal
3957- partitioning constraints, and only constraint exclusionwould be able
3958- to elidecertain partitions from the query plan using those .
3957+ even on declaratively-partitioned tables, in addition totheir internal
3958+ partition bounds, constraint exclusionmay be able
3959+ to elideadditional partitions from the query plan.
39593960 </para>
39603961
39613962 <para>
@@ -3986,15 +3987,15 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
39863987 clause contains constants (or externally supplied parameters).
39873988 For example, a comparison against a non-immutable function such as
39883989 <function>CURRENT_TIMESTAMP</function> cannot be optimized, since the
3989- planner cannot know whichpartition the function's value might fall
3990+ planner cannot know whichchild table the function's value might fall
39903991 into at run time.
39913992 </para>
39923993 </listitem>
39933994
39943995 <listitem>
39953996 <para>
39963997 Keep the partitioning constraints simple, else the planner may not be
3997- able to prove thatpartitions don't need to be visited. Use simple
3998+ able to prove thatchild tables might not need to be visited. Use simple
39983999 equality conditions for list partitioning, or simple
39994000 range tests for range partitioning, as illustrated in the preceding
40004001 examples. A good rule of thumb is that partitioning constraints should
@@ -4006,11 +4007,11 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
40064007
40074008 <listitem>
40084009 <para>
4009- All constraints on allpartitions of themaster table are examined
4010- during constraint exclusion, so large numbers ofpartitions are likely
4010+ All constraints on allchildren of theparent table are examined
4011+ during constraint exclusion, so large numbers ofchildren are likely
40114012 to increase query planning time considerably. So the legacy
40124013 inheritance based partitioning will work well with up to perhaps a
4013- hundredpartitions ; don't try to use many thousands ofpartitions .
4014+ hundredchild tables ; don't try to use many thousands ofchildren .
40144015 </para>
40154016 </listitem>
40164017