From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, emilioplatzer(at)gmail(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Documentation for create unique index is insuficient and (because of that) incorrect |
Date: | 2018-11-20 18:13:51 |
Message-ID: | 000aef3d-4183-d345-5d18-b811c4838160@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On 11/20/18 1:08 PM, Alvaro Herrera wrote:
> On 2018-Nov-20, Tom Lane wrote:
>
>> 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.
>
> That seems sensible.
+1
>
>> 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?
>
> I think right next to 11.5, which currently completes the topic of how
> are indexes used, is a good place.
I would vote at least before 11.9. You could make arguments how
understand how multicolumn, expression indexes, partials, etc. could be
more important, or at least used for frequently in the wild (at least
for now). And once we've explained those types then you could understand
how to use covering indexes appropriately.
Jonathan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-11-20 18:15:30 | Re: Documentation for create unique index is insuficient and (because of that) incorrect |
Previous Message | Alvaro Herrera | 2018-11-20 18:08:31 | Re: Documentation for create unique index is insuficient and (because of that) incorrect |