Re: POC: Parallel processing of indexes in autovacuum - Mailing list pgsql-hackers

From Daniil Davydov
Subject Re: POC: Parallel processing of indexes in autovacuum
Date
Msg-id CAJDiXgjoNd4BF19HNY_FAcDUqiqsfw8cGhNOJwBxahB8P38E3Q@mail.gmail.com
Whole thread Raw
In response to Re: POC: Parallel processing of indexes in autovacuum  (Daniil Davydov <3danissimo@gmail.com>)
Responses Re: POC: Parallel processing of indexes in autovacuum
List pgsql-hackers
Hi,

On Tue, Jan 6, 2026 at 3:44 AM Daniil Davydov <3danissimo@gmail.com> wrote:
>
> On Tue, Jan 6, 2026 at 1:51 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > Are you still working on it? Or shall I draft this part on top of the
> > 0001 patch?
>
> I thought about some "beautiful" approach, but for now I have
> only one idea - force parallel a/v workers to get values for these
> parameters from shmem (which obviously can be modified by the
> leader a/v process). I'll post this patch in the near future.
>

I am posting a draft version of the patch (see 0005) that allows parallel
leader to propagate changes of cost-based parameters to its parallel
workers. It is a very rough fix, but it reflects my idea that is to have some
shared state from which parallel workers can get values for the parameters
(and which only leader worker can modify, obviously).

I have also added a test that shows that this idea is working - the test
ensures that parallel workers can change its parameters if they have been
changed for the leader worker.

Note that so far the work is in progress - this logic works only for
vacuum_cost_delay and vacuum_cost_limits parameters. I think that we
should agree on an idea first, and only then apply logic for all appropriate
parameters.

What do you think?

--
Best regards,
Daniil Davydov

Attachment

pgsql-hackers by date:

Previous
From: myzhen
Date:
Subject: Re:Re: Fix incorrect column name in error message for range partition bound check
Next
From: John Naylor
Date:
Subject: Re: New commitfest app release on August 19th