postgres.git / summary / log / commit / refs
commit d5176fa1e3c38ee651c9937b33e673db7cd4d9e8
Author: Peter Eisentraut <peter_e@gmx.net>
Date: Thu Jul 05 20:51:56 2018 +0000
doc: Fix typos
Author: Justin Pryzby <pryzby@telsasoft.com>
doc/src/sgml/ddl.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index d9fb5c87dfd..1111d7ae842 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -3431,7 +3431,7 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
define any check constraints on this table, unless you intend them
to be applied equally to all partitions. There is no point in
defining any indexes or unique constraints on it, either. For our
- example, master table is the <structname>measurement</structname>
+ example, the master table is the <structname>measurement</structname>
table as originally defined.
</para>
</listitem>
@@ -3943,7 +3943,7 @@ 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 <literal>CHECK</literal>
constraints — which gives it its name — whereas partition
- pruning uses the table's partition bounds, which exists only in the
+ pruning uses the table's partition bounds, which exist 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.
[parent: aba2184bed64]