On 2017/04/01 6:37, Robert Haas wrote:
> On Tue, Mar 28, 2017 at 6:35 AM, Amit Langote
> <langote_amit...@lab.ntt.co.jp> wrote:
>> Attached updated patch.
>
> Committed with editing here and there. I just left out the thing
> about UNION ALL views, which seemed to brief a treatment to deserve
> its own subsection. Maybe a longer explanation of that is worthwhile
> or maybe it's not, but that can be a separate patch.
Thanks for committing.
I noticed what looks like a redundant line (or an incomplete sentence) in
the paragraph about multi-column partition keys. In the following text:
+ partitioning, if desired. Of course, this will often result in a
larger
+ number of partitions, each of which is individually smaller.
+ criteria. Using fewer columns may lead to coarser-grained
+ A query accessing the partitioned table will have
+ to scan fewer partitions if the conditions involve some or all of
these
This:
+ criteria. Using fewer columns may lead to coarser-grained
looks redundant. But maybe we can keep that sentence by completing it,
which the attached patch does as follows:
+ number of partitions, each of which is individually smaller. On the
+ other hand, using fewer columns may lead to a coarser-grained
+ partitioning criteria with smaller number of partitions.
The patch also fixes some typos I noticed.
Thanks,
Amit
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 5109778196..340c961b3f 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -2932,7 +2932,7 @@ VALUES ('Albany', NULL, NULL, 'NY');
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 table and partitions do not participate in
+ 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
@@ -3036,11 +3036,12 @@ CREATE TABLE measurement (
<para>
You may decide to use multiple columns in the partition key for range
partitioning, if desired. Of course, this will often result in a larger
- number of partitions, each of which is individually smaller.
- criteria. Using fewer columns may lead to coarser-grained
- A query accessing the partitioned table will have
- to scan fewer partitions if the conditions involve some or all of these
- columns. For example, consider a table range partitioned using columns
+ number of partitions, each of which is individually smaller. On the
+ other hand, using fewer columns may lead to a coarser-grained
+ partitioning criteria with smaller number of partitions. A query
+ accessing the partitioned table will have to scan fewer partitions if
+ the conditions involve some or all of these columns.
+ For example, consider a table range partitioned using columns
<structfield>lastname</> and <structfield>firstname</> (in that order)
as the partition key.
</para>
@@ -3167,8 +3168,8 @@ CREATE INDEX ON measurement_y2008m01 (logdate);
</para>
<para>
- The simplest option for removing old data is simply to drop the partition
- that is no longer necessary:
+ The simplest option for removing old data is to drop the partition that
+ is no longer necessary:
<programlisting>
DROP TABLE measurement_y2006m02;
</programlisting>
@@ -3595,8 +3596,8 @@ DO INSTEAD
<sect3 id="ddl-partitioning-inheritance-maintenance">
<title>Partition Maintenance</title>
<para>
- To remove old data quickly, simply to drop the partition that is no
- longer necessary:
+ To remove old data quickly, simply drop the partition that is no longer
+ necessary:
<programlisting>
DROP TABLE measurement_y2006m02;
</programlisting>
@@ -3692,7 +3693,7 @@ ANALYZE measurement;
Triggers or rules will be needed to route rows to the desired
partition, unless the application is explicitly aware of the
partitioning scheme. Triggers may be complicated to write, and will
- be much slower than the tuple routing performed interally by
+ be much slower than the tuple routing performed internally by
declarative partitioning.
</para>
</listitem>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
