Horton

Re: [HACKERS] CLUSTER command progress monitor

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

View thread View on postgr.es
From: Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>, Rafia Sabih <rafia.pghackers@gmail.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Jeff Janes <jeff.janes@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Michael Paquier <michael.paquier@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2019-09-06T14:27:02Z
Lists: pgsql-hackers 
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

Commits

  1. Fix progress reporting of CLUSTER / VACUUM FULL

  2. Fix thinko when ending progress report for a backend

  3. Report progress of REINDEX operations

  4. Add progress reporting for CLUSTER and VACUUM FULL.

  5. Un-hide most cascaded-drop details in regression test results.

  6. Fix memory leak in printtup.c.

  7. Remove unused macro