Re: POC: Parallel processing of indexes in autovacuum

Hi,

On Tue, Mar 31, 2026 at 2:09 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> I've made some changes to the documentation part, merged two patches
> into one, and updated the commit message. Please review the attached
> patch.
>

Great, thank you very much!

Again, I don't know how to write the documentation well, so you can ignore
my comments :

> + <command>VACUUM</command> can perform index vacuuming and index cleanup
Don't we need to mention autovacuum here too? I thought that VACUUM in the
context means "manual VACUUM command".

> + ...applies specifically to the index vacuuming and index cleanup phases...
Maybe we can refer to "vacuum-phases" here?

All other changes look good to me.

!!!
> Searching for arguments in
> favor of opt-in style, I asked for help from another person who has been
> managing the setup of highload systems for decades. He promised to share his
> opinion next week.

I talked to Anton Doroshkevich today.
He confirmed that as a rule there are *hundreds of thousands* of tables in the
system, the vast majority of which do not need to be vacuumed in parallel mode.

He also suggested the following : let the reloption overlap the value of the
GUC parameter. I.e. even if av_max_parallel_workers parameters is 0 the user
still can set the av_parallel_workers to 10 for some table, and autovacuum
will process this table in parallel.

I remember that you want to use the GUC parameter as a global switch, and this
approach will break this logic. But according to Anton's words, it is okay if
the GUC parameter cannot disable parallel a/v for all tables instantly. It will
become an administrator's responsibility to manually turn off parallel a/v for
several tables (again, it is completely OK). Thus, this feature can be handy
for all use cases.

I hope it doesn't look like as an adapting to the needs of a specific user.
A lot of super-large productions are migrating to postgres now, and I believe
that we should ensure their comfort too.

What do you think? Can postgres have such a logic?

--
Best regards,
Daniil Davydov