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
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 |