Hi, On Tue, Mar 31, 2026 at 2:09 PM Masahiko Sawada <[email protected]> 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
