From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, emilioplatzer(at)gmail(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: Documentation for create unique index is insuficient and (because of that) incorrect |
Date: | 2018-11-20 17:57:45 |
Message-ID: | 25342.1542736665@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
I wrote:
> "Jonathan S. Katz" <jkatz(at)postgresql(dot)org> writes:
>> Also +1 on having a section on covering indexes.
> I see Alvaro is on the same page here. I'll go write something
> later today.
So looking closer ... not only is the unique-index section not a very
good fit, but there is already a section that this does fit into
pretty well, which is 11.11 on index-only scans. Not only do you need
to understand index-only scans to understand why you'd want INCLUDE,
but there's already discussion there of making covering indexes the
hard way.
So what I think I should do is reformulate that discussion to talk
about making covering indexes with INCLUDE, and then mention in
passing that you can also do it without that as long as you don't mind
the payload columns being part of the index semantics.
I'm also wondering whether to move that section someplace earlier
in chapter 11. Right now it's near the end because it's mostly
info about an implementation detail; but it wouldn't be hard to
make the argument that covering indexes are more important than,
say, indexes with custom collations. Should we move it, and if
so to where?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-11-20 18:08:31 | Re: Documentation for create unique index is insuficient and (because of that) incorrect |
Previous Message | Tom Lane | 2018-11-20 15:16:42 | Re: Documentation for create unique index is insuficient and (because of that) incorrect |