Re: monitoring CREATE INDEX [CONCURRENTLY]
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>,
Rahila Syed <rahila.syed@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>,
Simon Riggs <simon@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@lists.postgresql.org>,
David Fetter <david@fetter.org>, Pavan Deolasee <pavan.deolasee@gmail.com>,
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Date: 2019-04-05T14:46:53Z
Lists: pgsql-hackers
Attachments
- 0001-Report-progress-of-REINDEX-operations.patch (text/plain) patch 0001
It seems we can easily extend this to also monitor REINDEX [CONCURRENTLY]. Attached is a quick patch. For the concurrently part, we currently don't have any phases defined for the index swap and drop, but maybe we can just skip that initially. What happens if we don't have those? It might be nice to have a column in the view not only for the table OID but also the index OID. That is obviously not so useful for CREATE INDEX but more useful for REINDEX. I haven't looked into how adding that would work. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Report progress of REINDEX operations
- 03f9e5cba0ee 12.0 landed
-
Report progress of CREATE INDEX operations
- ab0dfc961b6a 12.0 landed
-
Fix error handling of readdir() port implementation on first file lookup
- 754b90f657bd 12.0 cited