> The arguments of pgstat_progress_update_param() would be given by the > worker directly as components of the 'P' message. It seems to me that > this approach would have the simplicity to not require the setup of a > shmem area for the extra counters, and there would be no need for a > callback. Hence, the only thing the code paths of workers would need > to do is to call this routine, then the leaders would increment their > progress when they see a CFI to process the 'P' message. Also, I > guess that we would only need an interface in backend_progress.c to > increment counters, like pgstat_progress_incr_param(), but usable by > workers. Like a pgstat_progress_worker_incr_param()?
So, here is what I think should be workable to give a generic progress interface. pgstat_progress_parallel_incr_param will be a new API that can be called by either worker of leader from any parallel code path that chooses to increment a progress index. If called by a worker, it will send a 'P' message to the front end passing both the progress index, i.e. PROGRESS_VACUUM_INDEXES_PROCESSED And the value to increment by, i.e. 1 for index vacuum progress. With that, the additional shared memory counters in ParallelVacuumState are not needed, and the poke of the worker to the leader goes directly through a generic backend_progress API. Let me know your thoughts. Thanks! -- Sami Imseih Amazon Web Services (AWS)
v27-0001-Report-index-vacuum-progress.patch
Description: v27-0001-Report-index-vacuum-progress.patch
