Re: POC: Parallel processing of indexes in autovacuum
Daniil Davydov <3danissimo@gmail.com>
From: Daniil Davydov <3danissimo@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
Sami Imseih <samimseih@gmail.com>, Matheus Alcantara <matheusssilv97@gmail.com>,
Maxim Orlov <orlovmg@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-01T21:24:29Z
Lists: pgsql-hackers
Attachments
- v36-0001-Allow-autovacuum-to-use-parallel-vacuum-workers.patch (text/x-patch) patch v36-0001
- v35-v36-diff.patch (text/x-patch) patch v35
Hi, On Wed, Apr 1, 2026 at 7:10 PM Alexander Korotkov <aekorotkov@gmail.com> wrote: > > Thank you for your work on this subject! I've some notes about the patch. > Thank you very much for the review! > 1) The changes in guc.c allows autovacuum parallel leader to accept > changes in not just cost-based GUCs, but any GUCs. That should be no > problem, because parallel workers have their own copies of GUC > variables, but I think this worth comment. OK, I will clarify it in the code. > 2) Maximum value for autovacuum_parallel_workers reloption is defined > as literally 1024, while max value for autovacuum_max_parallel_workers > is defined as MAX_PARALLEL_WORKER_LIMIT (also 1024). Should we define > max value for reloption as MAX_PARALLEL_WORKER_LIMIT as well? I agree. > 3) Some paragraphs were moved from vacuum.sgml to maintenance.sgml. > It particular it references <replaceable > class="parameter">integer</replaceable, which is related to PARALLEL > option syntax: (PARALLEL integer). Now it becoming unclear and needs > to be revised. Good catch! You are right. > 4) I also think maintenance.sgml should mention the new reloption. Do you mean that we should mention it in the "parallel-vacuum" chapter? If so, I think that we should also mention that max_parallel_maintenance_workers can affect the parallel degree of manual VACUUM command. Yes, we have already written about this in the description of the PARALLEL option. But now the "vacuum-parallel" chapter doesn't mention limiting by GUC for manual VACUUM and limiting by reloption for autovacuum. IMHO it is better to have redundancy than an incomplete description. > 5) I think it worth having a test which check that setting > autovacuum_parallel_workers to 0 disables the parallel autovacuum for > given table. I see that VACUUM (PARALLEL) doesn't have such a test. Both manual VACUUM and autovacuum have similar logic with parallelism disabling. Is the increase in test completion time really worth checking these logic? I don't mind adding a new test, actually. Just want to make sure that this is necessary. > 6) Minor grammar issue in PVSharedCostParams comment, it must be > "vacuum workers compare" (plural subject). Yep, I'll fix it. Please, see an updated patch. -- Best regards, Daniil Davydov
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow autovacuum to use parallel vacuum workers.
- 1ff3180ca016 19 (unreleased) landed
-
Add parallel vacuum worker usage to VACUUM (VERBOSE) and autovacuum logs.
- adcdbe93860b 19 (unreleased) landed
-
doc: Put new options in consistent order on man pages
- bc35adee8d7a 18.0 cited