From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com> |
Subject: | Re: WIP: Covering + unique indexes. |
Date: | 2018-01-26 04:19:16 |
Message-ID: | CAEepm=2gh3nKi2u18i4r=TLhMyZf6guWSwmrHEcwm7dyJahnow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 26, 2018 at 3:01 AM, Anastasia Lubennikova
<a(dot)lubennikova(at)postgrespro(dot)ru> wrote:
> Thanks for the reminder. Rebased patches are attached.
This is a really cool and also difficult feature. Thanks for working
on it! Here are a couple of quick comments on the documentation,
since I noticed it doesn't build:
SGML->XML change: (1) empty closing tags "</>" are no longer accepted,
(2) <xref ...> now needs to be written <xref .../> and (3) xref IDs
are now case-sensitive.
+ PRIMARY KEY ( <replaceable
class="parameter">column_name</replaceable> [, ... ] ) <replaceable
class="parameter">index_parameters</replaceable> <optional>INCLUDE
(<replaceable class="parameter">column_name</replaceable> [,
...])</optional> |
I hadn't seen that use of "<optional>" before. Almost everywhere else
we use explicit [ and ] characters, but I see that there are other
examples, and it is rendered as [ and ] in the output. OK, cool, but
I think there should be some extra whitespace so that it comes out as:
[ INCLUDE ... ]
instead of:
[INCLUDE ...]
to fit with the existing convention.
+ ... This also allows <literal>UNIQUE</> indexes to be defined on
+ 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 used in the
+ <literal>INCLUDE</> clause, which can slightly reduce the
size of the index.
Can I suggest rewording these three sentences a bit? Just an idea:
<literal>UNIQUE</literal> indexes, <literal>PRIMARY KEY</literal>
constraints and <literal>EXCLUDE</literal> constraints can be defined
with extra columns in an <literal>INCLUDE</literal> clause, in which
case uniqueness is not enforced for the extra columns. Moving columns
that are not needed for searching, ordering or uniqueness into the
<literal>INCLUDE</literal> clause can sometimes reduce the size of the
index while retaining the possibility of using a faster index-only
scan.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-01-26 05:10:24 | Re: Redefining inet_net_ntop |
Previous Message | Peter Eisentraut | 2018-01-26 03:26:55 | Re: [HACKERS] generated columns |