Hi, On Fri, Apr 3, 2026 at 6:31 AM Masahiko Sawada <[email protected]> wrote: > > What do you think about the idea of using proc signals like the patch > I've sent recently[1]? With that approach, workers have to check the > local variable. It seems slightly cheaper and can use the existing > logic. >
Thank you for the patch! 1) Maybe we should implement this logic within ParallelMessages? For example, I see this ParallelMessages use case in parallel a/v : /* * Call the parallel variant of pgstat_progress_incr_param so workers can * report progress of index vacuum to the leader. */ pgstat_progress_parallel_incr_param(PROGRESS_VACUUM_INDEXES_PROCESSED, 1); I.e. parallel a/v workers already communicate with a leader via ParallelMessages, so it will be convenient to extend this protocol by a new message. 2) I don't think that the difference between accessing atomic and local variable can be measured for parallel workers. But sending a signal to every parallel worker is surely slower than just incrementing an atomic variable. IIUC you created this patch in order to solve the task of using an existing infrastructure instead of creating a new utilitarian solution. However, I think that both the polling approach and signalling approach (in its current implementation) are basically equal. I mean that in both cases we have an autovacuum-specific mechanism to share particular parameters between particular workers. I will try to explain how I see the solution to this problem. : Your implementation can be made more abstract, so that it becomes a new internal mechanism that other modules can use in the future. E.g. we can create an interface that allows any parallel leader (not necessarily just an autovacuum leader) to inform its parallel workers that some config parameters have been changed. At the same time, parallel workers can use this interface in order to specify, which parameters (or groups of parameters) they want to consume from the leader. What do you think? -- Best regards, Daniil Davydov
