Re: [patch] Concurrent table reindex per-index progress reporting - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [patch] Concurrent table reindex per-index progress reporting
Date
Msg-id 20200929053050.GA7117@paquier.xyz
Whole thread Raw
In response to Re: [patch] Concurrent table reindex per-index progress reporting  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List pgsql-hackers
On Fri, Sep 25, 2020 at 11:32:11AM +0200, Matthias van de Meent wrote:
> Updating to WAIT_1 was to set it back to whatever the state was before
> we would get into the loop and start_command was called. I quite
> apparently didn't take enough care to set all fields that could be
> set, though, so thanks for noticing.

I have been considering that, and I can see your point.  Not setting
the phase has the disadvantage to set it to "initializing" when
starting the command tracking, even for a very short time, and that
could be confusing as we state in the docs that this refers to the
point where the indexes are created.  So, instead, I have actually set
the phase to "build" or "validate".  As we are updating three times
the same four fields (phase, table OID, index OID and index AM) for
the concurrent creation, index build and validation, I have switched
the implementation to use a multi-param update instead everywhere, and
applied it down to 12.  Thanks for the report, Matthias.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "k.jamison@fujitsu.com"
Date:
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist
Next
From: Michael Paquier
Date:
Subject: Re: SQL-standard function body