@@ -143,17 +143,23 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
143143 <term><literal>INCLUDING</literal></term>
144144 <listitem>
145145 <para>
146- This clause specifies additional columns to be appended to the set of index columns.
147- Included columns don't support any constraints <literal>(UNIQUE, PRMARY KEY, EXCLUSION CONSTRAINT)</>.
148- These columns can improve the performance of some queries through using advantages of index-only scan
149- (Or so called <firstterm>covering</firstterm> indexes. Covering index is the index that
150- covers all columns required in the query and prevents a table access).
151- Besides that, included attributes are not stored in index inner pages.
152- It allows to decrease index size and furthermore it provides a way to extend included
153- columns to store atttributes without suitable opclass (not implemented yet).
154- This clause could be applied to both unique and nonunique indexes.
155- It's possible to have non-unique covering index, which behaves as a regular
156- multi-column index with a bit smaller index-size.
146+ An optional <literal>INCLUDING</> clause allows a list of columns to be
147+ specified which will be included in the index, in the non-key portion of
148+ the index. Columns which are part of this clause cannot also exist in the
149+ key columns portion of the index, and vice versa. The
150+ <literal>INCLUDING</> columns exist solely to allow more queries to benefit
151+ from <firstterm>index-only scans</> by including certain columns in the
152+ index, the value of which would otherwise have to be obtained by reading
153+ the table's heap. Having these columns in the <literal>INCLUDING</> clause
154+ in some cases allows <productname>PostgreSQL</> to skip the heap read
155+ completely. This also allows <literal>UNIQUE</> indexes to be defined on
156+ one set of columns, which can include another set of column in the
157+ <literal>INCLUDING</> clause, on which the uniqueness is not enforced upon.
158+ It's the same with other constraints (PRIMARY KEY and EXCLUDE). This can
159+ also can be used for non-unique indexes as any columns which are not required
160+ for the searching or ordering of records can defined in the
161+ <literal>INCLUDING</> clause, which can slightly reduce the size of the index,
162+ due to storing included attributes only in leaf index pages.
157163 Currently, only the B-tree access method supports this feature.
158164 </para>
159165 </listitem>
@@ -617,15 +623,15 @@ Indexes:
617623 <title>Examples</title>
618624
619625 <para>
620- To createan unique B-tree index on the column <literal>title</literal> in
626+ To createa unique B-tree index on the column <literal>title</literal> in
621627 the table <literal>films</literal>:
622628<programlisting>
623629CREATE UNIQUE INDEX title_idx ON films (title);
624630</programlisting>
625631 </para>
626632
627633 <para>
628- To createan unique B-tree index on the column <literal>title</literal>
634+ To createa unique B-tree index on the column <literal>title</literal>
629635 and included columns <literal>director</literal> and <literal>rating</literal>
630636 in the table <literal>films</literal>:
631637<programlisting>