Re: Add index scan progress to pg_stat_progress_vacuum
От | Peter Geoghegan |
---|---|
Тема | Re: Add index scan progress to pg_stat_progress_vacuum |
Дата | |
Msg-id | CAH2-Wzmk7fJuUNVX85AR3eS7MUGait7LrbhP8_8Y74W=m61Hnw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add index scan progress to pg_stat_progress_vacuum ("Imseih (AWS), Sami" <simseih@amazon.com>) |
Ответы |
Re: Add index scan progress to pg_stat_progress_vacuum
|
Список | 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 isturned 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
В списке pgsql-hackers по дате отправления: