Re: Add index scan progress to pg_stat_progress_vacuum
Nathan Bossart <bossartn@amazon.com>
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>, "Imseih (AWS), Sami" <simseih@amazon.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Peter Geoghegan <pg@bowt.ie>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-01-12T19:28:23Z
Lists: pgsql-hackers
On 1/11/22, 11:46 PM, "Masahiko Sawada" <sawada.mshk@gmail.com> wrote: > Regarding the new pg_stat_progress_vacuum_index view, why do we need > to have a separate view? Users will have to check two views. If this > view is expected to be used together with and joined to > pg_stat_progress_vacuum, why don't we provide one view that has full > information from the beginning? Especially, I think it's not useful > that the total number of indexes to vacuum (num_indexes_to_vacuum > column) and the current number of indexes that have been vacuumed > (index_ordinal_position column) are shown in separate views. I suppose we could add all of the new columns to pg_stat_progress_vacuum and just set columns to NULL as appropriate. But is that really better than having a separate view? > Also, I’m not sure how useful index_tuples_removed is; what can we > infer from this value (without a total number)? I think the idea was that you can compare it against max_dead_tuples and num_dead_tuples to get an estimate of the current cycle progress. Otherwise, it just shows that progress is being made. Nathan [0] https://postgr.es/m/7874FB21-FAA5-49BD-8386-2866552656C7%40amazon.com
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