Horton

Re: [DOC] Document concurrent index builds waiting on each other

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: James Coleman <jtc331@gmail.com>, David Johnston <david.g.johnston@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2020-11-30T21:52:55Z
Lists: pgsql-hackers

Attachments

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?

Commits

  1. Call out vacuum considerations in create index docs

  2. Document concurrent indexes waiting on each other

  3. snapshot scalability: Don't compute global horizons while building snapshots.

  4. Remove PROC_IN_ANALYZE and derived flags

  5. Improve performance of get_actual_variable_range with recently-dead tuples.