On Tue, 16 Feb 2021, 07:42 Justin Pryzby, <pry...@telsasoft.com> wrote: > > It looks like we missed this in a6642b3ae. > > I think it's an odd behavior of pg_stat_progress_create_index to > simultaneously > show the global progress as well as the progress for the current partition ... > > It seems like for partitioned reindex, reindex_index() should set the AM, > which > is used in the view: > > src/backend/catalog/system_views.sql- WHEN 2 THEN > 'building index' || > src/backend/catalog/system_views.sql: COALESCE((': > ' || pg_indexam_progress_phasename(S.param9::oid, S.param11)), > > Maybe it needs a new flag, like: > params->options & REINDEXOPT_REPORT_PROGRESS_AM > > I don't understand why e66bcfb4c added multiple calls to > pgstat_progress_start_command().
These were added to report the index and table that are currently being worked on in concurrent reindexes of tables, schemas and databases. Before that commit, it would only report up to the last index being prepared in phase 1, leaving the user with no info on which index is being rebuilt. Why pgstat_progress_start_command specifically was chosen? That is because there is no method to update the beentry->st_progress_command_target other than through stat_progress_start_command, and according to the docs that field should contain the tableId of the index that is currently being worked on. This field needs a pgstat_progress_start_command because CIC / RiC reindexes all indexes concurrently at the same time (and not grouped by e.g. table), so we must re-start reporting for each index in each new phase in which we report data to get the heapId reported correctly for that index. With regards, Matthias van de Meent