From: Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>
Cc: Rafia Sabih <rafia.pghackers@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Subject: Re: [HACKERS] CLUSTER command progress monitor
Date: Fri, 6 Sep 2019 10:27:02 -0400
Message-ID: <20190906142702.GA8947@alvherre.pgsql> (raw)
In-Reply-To: <20190906054418.GC1608@paquier.xyz>
On 2019-Sep-06, Michael Paquier wrote:
> Finally comes the question of what do we do for v12? I am adding in
> CC Peter, Alvaro being already present, who have been involved in the
> commits with CREATE INDEX and REINDEX. It would be sad to revert a
> this feature, but well I'd rather do that now than regret later
> releasing the feature as it is currently shaped.. Let's see what the
> others think.
As far as I understand, CREATE INDEX is not affected -- only REINDEX is.
Of course, it would be sad to revert even the latter, but it's not as
bleak as reverting the whole thing.
That said, I did spend some time on this type of issue when doing CREATE
INDEX support; you can tell because I defined the columns for block
numbers in a scan separately from CREATE INDEX specific fields,
precisely to avoid multiple commands running concurrently from
clobbering unrelated columns:
/* Block numbers in a generic relation scan */
#define PROGRESS_SCAN_BLOCKS_TOTAL 15
#define PROGRESS_SCAN_BLOCKS_DONE 16
I would say that it's fairly useful to have CLUSTER report progress on
indexes being created underneath, but I understand that it might be too
late to be designing the CLUSTER report to take advantage of the CREATE
INDEX metrics.
I think a workable, not terribly invasive approach is to have REINDEX
process its commands conditionally: have the caller indicate whether
progress is to be reported, and skip the calls if not. That would
(should) prevent it from clobbering the state set up by CLUSTER.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@alvh.no-ip.org, michael@paquier.xyz, robertmhaas@gmail.com, sawada.mshk@gmail.com, tatsuro.yamada.tf@nttcom.co.jp, rafia.pghackers@gmail.com, 9erthalion6@gmail.com, pg@bowt.ie, jeff.janes@gmail.com, thomas.munro@enterprisedb.com, michael.paquier@gmail.com, peter.eisentraut@2ndquadrant.com
Subject: Re: [HACKERS] CLUSTER command progress monitor
In-Reply-To: <20190906142702.GA8947@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox