From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | James Coleman <jtc331(at)gmail(dot)com>, David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: [DOC] Document concurrent index builds waiting on each other |
Date: | 2020-11-30 21:52:55 |
Message-ID: | 20201130215255.GA4219@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-Sep-30, Michael Paquier wrote:
> + <para>
> + <command>CREATE INDEX</command> (including the <literal>CONCURRENTLY</literal>
> + option) commands are included when <command>VACUUM</command> calculates what
> + dead tuples are safe to remove even on tables other than the one being indexed.
> + </para>
> FWIW, this is true as well for REINDEX CONCURRENTLY because both use
> the same code paths for index builds and validation, with basically
> the same waiting phases. But is CREATE INDEX the correct place for
> that? Wouldn't it be better to tell about such things on the VACUUM
> doc?
Yeah, I think it might be more sensible to document this in
maintenance.sgml, as part of the paragraph that discusses removing
tuples "to save space". But making it inline with the rest of the flow,
it seems to distract from higher-level considerations, so I suggest to
make it a footnote instead.
I'm not sure on the wording to use; what about this?
Attachment | Content-Type | Size |
---|---|---|
v5-0001-Note-CIC-and-RC-in-vacuum-s-doc.patch | text/x-diff | 1.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-11-30 21:56:34 | Re: proposal: unescape_text function |
Previous Message | Tom Lane | 2020-11-30 21:34:29 | Re: support IncrementalSortPath type in outNode() |