Re: POC: Parallel processing of indexes in autovacuum

Hi,

On Fri, Apr 3, 2026 at 6:31 AM Masahiko Sawada <sawada.mshk@gmail.com> 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