Re: Add index scan progress to pg_stat_progress_vacuum
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: "Bossart, Nathan" <bossartn@amazon.com>
Cc: "Imseih (AWS), Sami" <simseih@amazon.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-12-20T18:37:05Z
Lists: pgsql-hackers
On Wed, Dec 15, 2021 at 2:10 PM Bossart, Nathan <bossartn@amazon.com> wrote: > nitpick: Shouldn't index_blks_scanned be index_blks_vacuumed? IMO it > is more analogous to heap_blks_vacuumed. +1. > This will tell us which indexes are currently being vacuumed and the > current progress of those operations, but it doesn't tell us which > indexes have already been vacuumed or which ones are pending vacuum. VACUUM will process a table's indexes in pg_class OID order (outside of parallel VACUUM, I suppose). See comments about sort order above RelationGetIndexList(). Anyway, it might be useful to add ordinal numbers to each index, that line up with this processing/OID order. It would also be reasonable to display the same number in log_autovacuum* (and VACUUM VERBOSE) per-index output, to reinforce the idea. Note that we don't necessarily display a distinct line for each distinct index in this log output, which is why including the ordinal number there makes sense. > I wish option #1 was cleaner, because I think it would be really nice > to have all this information in a single row. I do too. I agree with the specific points you raise in your remarks about what you've called options #2 and #3, but those options still seem unappealing to me. -- Peter Geoghegan
Commits
-
Report index vacuum progress.
- 46ebdfe164c6 17.0 landed
-
Add new parallel message type to progress reporting.
- f1889729dd3a 17.0 landed
-
Remove MaxBackends variable in favor of GetMaxBackends() function.
- aa64f23b0292 15.0 cited