On Thu, Apr 06, 2023 at 03:14:20PM +0000, Imseih (AWS), Sami wrote: >> Could it be worth thinking about a different design where >> the value incremented and the parameters of >> pgstat_progress_update_param() are passed through the 'P' message >> instead? > > I am not sure how this is different than the approach suggested. > In the current design, the 'P' message is used to pass the > ParallelvacuumState to parallel_vacuum_update_progress which then > calls pgstat_progress_update_param.
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()? -- Michael
signature.asc
Description: PGP signature
