On 2017-01-09 16:02, Anastasia Lubennikova wrote:
include_columns_10.0_v1.patch
The patch applies, compiles, and make check is OK.
It yields nice perfomance gains and I haven't been able to break
anything (yet).
Some edits of the sgml-changes are attached.
Thank you for this very useful improvement.
Erik Rijkers
--- doc/src/sgml/catalogs.sgml.orig 2017-01-10 03:40:52.649761572 +0100
+++ doc/src/sgml/catalogs.sgml 2017-01-10 03:53:13.408298695 +0100
@@ -3598,7 +3598,7 @@
<entry><type>int2</type></entry>
<entry></entry>
<entry>The number of key columns in the index. "Key columns" are ordinary
- index columns in contrast with "included" columns.</entry>
+ index columns (as opposed to "included" columns).</entry>
</row>
<row>
--- doc/src/sgml/ref/create_index.sgml.orig 2017-01-10 03:14:25.603940872 +0100
+++ doc/src/sgml/ref/create_index.sgml 2017-01-10 03:22:20.013526245 +0100
@@ -153,16 +153,15 @@
the table's heap. Having these columns in the <literal>INCLUDE</> clause
in some cases allows <productname>PostgreSQL</> to skip the heap read
completely. This also allows <literal>UNIQUE</> indexes to be defined on
- one set of columns, which can include another set of column in the
- <literal>INCLUDE</> clause, on which the uniqueness is not enforced upon.
+ one set of columns, which can include another set of columns in the
+ <literal>INCLUDE</> clause, on which the uniqueness is not enforced.
It's the same with other constraints (PRIMARY KEY and EXCLUDE). This can
also can be used for non-unique indexes as any columns which are not required
- for the searching or ordering of records can be included in the
- <literal>INCLUDE</> clause, which can slightly reduce the size of the index,
- due to storing included attributes only in leaf index pages.
+ for the searching or ordering of records can be used in the
+ <literal>INCLUDE</> clause, which can slightly reduce the size of the index.
Currently, only the B-tree access method supports this feature.
Expressions as included columns are not supported since they cannot be used
- in index-only scan.
+ in index-only scans.
</para>
</listitem>
</varlistentry>
--- doc/src/sgml/ref/create_table.sgml.orig 2017-01-10 03:15:17.033377433 +0100
+++ doc/src/sgml/ref/create_table.sgml 2017-01-10 03:34:57.541537576 +0100
@@ -615,9 +615,9 @@
<para>
Adding a unique constraint will automatically create a unique btree
index on the column or group of columns used in the constraint.
- Optional clause <literal>INCLUDE</literal> allows to add into the index
- a portion of columns on which the uniqueness is not enforced upon.
- Note, that althogh constraint is not enforced upon included columns, it still
+ The optional clause <literal>INCLUDE</literal> adds to that index
+ one or more columns on which the uniqueness is not enforced.
+ Note that although the constraint is not enforced on the included columns, it still
depends on them. Consequently, some operations on these columns (e.g. <literal>DROP COLUMN</literal>)
can cause cascade constraint and index deletion.
See paragraph about <literal>INCLUDE</literal> in
@@ -659,7 +659,7 @@
index on the column or group of columns used in the constraint.
An optional <literal>INCLUDE</literal> clause allows a list of columns
to be specified which will be included in the non-key portion of the index.
- Althogh uniqueness is not enforced on the included columns, the constraint
+ Although uniqueness is not enforced on the included columns, the constraint
still depends on them. Consequently, some operations on the included columns
(e.g. <literal>DROP COLUMN</literal>) can cause cascade constraint and index deletion.
See paragraph about <literal>INCLUDE</literal> in
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
