Re: Add index scan progress to pg_stat_progress_vacuum
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: "Imseih (AWS), Sami" <simseih@amazon.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, "Bossart,
Nathan" <bossartn@amazon.com>, Masahiko Sawada <sawada.mshk@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-02-23T18:41:36Z
Lists: pgsql-hackers
On Wed, Feb 23, 2022 at 10:02 AM Imseih (AWS), Sami <simseih@amazon.com> wrote: > If the failsafe kicks in midway through a vacuum, the number indexes_total will not be reset to 0. If INDEX_CLEANUP is turned off, then the value will be 0 at the start of the vacuum. The way that this works with num_index_scans is that we "round up" when there has been non-zero work in lazy_vacuum_all_indexes(), but not if the precheck in lazy_vacuum_all_indexes() fails. That seems like a good model to generalize from here. Note that this makes INDEX_CLEANUP=off affect num_index_scans in much the same way as a VACUUM where the failsafe kicks in very early, during the initial heap pass. That is, if the failsafe kicks in before we reach lazy_vacuum() for the first time (which is not unlikely), or even in the lazy_vacuum_all_indexes() precheck, then num_index_scans will remain at 0, just like INDEX_CLEANUP=off. The actual failsafe WARNING shows num_index_scans, possibly before it gets incremented one last time (by "rounding up"). So it's reasonably clear how this all works from that context (assuming that the autovacuum logging stuff, which reports num_index_scans, outputs a report for a table where the failsafe kicked in). -- 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