On 2018-04-05 00:09, Alexander Korotkov wrote:
Hi!
Thank you for review! Revised patchset is attached.
[0001-Covering-core-v12.patch]
[0002-Covering-btree-v12.patch]
[0003-Covering-amcheck-v12.patch]
[0004-Covering-natts-v12.patch]
Really nice performance gains.
I read through the docs and made some changes. I hope it can count as
improvement.
It would probably also be a good idea to add the term "covering index"
somewhere, at least in the documentation's index; the term does now not
occur anywhere. (This doc-patch does not add it)
thanks,
Erik Rijkers
--- doc/src/sgml/ref/create_index.sgml.orig 2018-04-05 14:36:00.904617793 +0200
+++ doc/src/sgml/ref/create_index.sgml 2018-04-05 15:49:03.778805965 +0200
@@ -148,31 +148,27 @@
<term><literal>INCLUDE</literal></term>
<listitem>
<para>
- An optional <literal>INCLUDE</literal> clause allows to specify the
- list of columns which will be included in the non-key part of the index.
- Columns listed in this clause cannot co-exist as index key columns,
- and vice versa. The <literal>INCLUDE</literal> columns exist solely to
+ The optional <literal>INCLUDE</literal> clause specifies a
+ list of columns which will be included as a non-key part in the index.
+ Columns listed in this clause cannot also be present as index key columns.
+ The <literal>INCLUDE</literal> columns exist solely to
allow more queries to benefit from <firstterm>index-only scans</firstterm>
- by including specified columns into the index. Values of these columns
+ by including the values of the specified columns in the index. These values
would otherwise have to be obtained by reading the table's heap.
- Having these columns in the <literal>INCLUDE</literal> clause
- in some cases allows <productname>PostgreSQL</productname> to skip
- the heap read completely.
</para>
<para>
- In the <literal>UNIQUE</literal> indexes, uniqueness is only enforced
+ In <literal>UNIQUE</literal> indexes, uniqueness is only enforced
for key columns. Columns listed in the <literal>INCLUDE</literal>
- clause have no influence to uniqueness enforcement. Other constraints
+ clause have no effect on uniqueness enforcement. Other constraints
(PRIMARY KEY and EXCLUDE) work the same way.
</para>
<para>
- Columns listed in the <literal>INCLUDE</literal> clause doesn't need
- appropriate operator class to exist. Therefore,
- <literal>INCLUDE</literal> clause if useful to add non-key index
- columns, whose data types don't have operator classes defined for
- given access method.
+ Columns listed in the <literal>INCLUDE</literal> clause don't need
+ appropriate operator classes; the clause can contain non-key index
+ columns whose data types don't have operator classes defined for
+ a given access method.
</para>
<para>
@@ -182,12 +178,12 @@
<para>
Currently, only the B-tree index access method supports this feature.
- In B-tree indexes, values of columns listed in the
- <literal>INCLUDE</literal> clause are included into leaf tuples which
- are linked to the heap tuples, but aren't included into pivot tuples
+ In B-tree indexes, the values of columns listed in the
+ <literal>INCLUDE</literal> clause are included in leaf tuples which
+ are linked to the heap tuples, but are not included into pivot tuples
used for tree navigation. Therefore, moving columns from the list of
key columns to the <literal>INCLUDE</literal> clause can slightly
- reduce index size and improve tree branching factor.
+ reduce index size and improve the tree branching factor.
</para>
</listitem>
</varlistentry>
