Re: [patch] Concurrent table reindex per-index progress reporting

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] Concurrent table reindex per-index progress reporting
Date: 2020-09-29 05:30:50
Message-ID: 20200929053050.GA7117@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-09-29 05:42:01 Re: SQL-standard function body
Previous Message k.jamison@fujitsu.com 2020-09-29 04:04:16 RE: [Patch] Optimize dropping of relation buffers using dlist