| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Daniil Davydov <3danissimo(at)gmail(dot)com> |
| Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: POC: Parallel processing of indexes in autovacuum |
| Date: | 2026-04-04 01:11:58 |
| Message-ID: | CAD21AoBwzPC-oo=yyfdVBC6hadjOSbKyHSs7bH7DqPUamAEZfg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 3, 2026 at 6:45 AM Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Fri, Apr 3, 2026 at 6:00 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Thu, Apr 2, 2026 at 8:10 AM Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:
> > >
> > > I think we should add some cleanup for autovacuum near the ParallelContext
> > > cleanup, since they are interconnected. I also want to return our tests that
> > > are triggering ERROR/PANIC in the leader worker in order to check whether all
> > > resources are released. I hope I will be able to get to that by tomorrow
> > > evening.
> >
> > I think that the beginning of vacuum loop (in PG_TRY() block in
> > vacuum()) seems better place as we're resetting vacuum delay
> > parameters:
> >
> > in_vacuum = true;
> > VacuumFailsafeActive = false;
> > VacuumUpdateCosts();
> > VacuumCostBalance = 0;
> > VacuumCostBalanceLocal = 0;
> > VacuumSharedCostBalance = NULL;
> > VacuumActiveNWorkers = NULL;
> >
>
> I am still thinking that this pointer is related to the ParallelContext, and it
> is a bit confusing that we can manipulate it outside all "parallel" logic.
> Since this variable points to the DSM it looks very natural for me if its
> lifetime will be similar to the DSM. Please, see attached patch, that resets
> this pointer during dsm detaching.
Sounds a reasonable apporach.
Regarding the regression tests, ISTM we no longer need
'autovacuum-leader-before-indexes-processing' injection point since it
currently tests that parallel workers update their delay parameters
during the initialization (i.e., in parallel_vacuum_main()). In order
to verify the behavior of workers updating their delay parameters
while processing indexes, we would need another injection ponit to
stop parallel workers, which seems overkill to me. So I removed it but
the test still covers the propagation logic.
Regarding the patch, I don't think it's a good idea to include
bgworker_internals.h from reloptions.c:
@@ -28,6 +28,7 @@
#include "commands/defrem.h"
#include "commands/tablespace.h"
#include "nodes/makefuncs.h"
+#include "postmaster/bgworker_internals.h"
#include "storage/lock.h"
#include "utils/array.h"
#include "utils/attoptcache.h"
@@ -236,6 +237,15 @@ static relopt_int intRelOpts[] =
},
SPGIST_DEFAULT_FILLFACTOR, SPGIST_MIN_FILLFACTOR, 100
},
+ {
+ {
+ "autovacuum_parallel_workers",
+ "Maximum number of parallel autovacuum workers that can be
used for processing this table.",
+ RELOPT_KIND_HEAP,
+ ShareUpdateExclusiveLock
+ },
+ -1, -1, MAX_PARALLEL_WORKER_LIMIT
+ },
I'd leave the maximum value as 1024.
I've attached patch and please check it. I think it's a good shape and
I'm going to push it next Monday barrying objections.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
| Attachment | Content-Type | Size |
|---|---|---|
| v37-0001-Allow-autovacuum-to-use-parallel-vacuum-workers.patch | text/x-patch | 42.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-04-04 01:24:55 | Re: AIO / read stream heuristics adjustments for index prefetching |
| Previous Message | Thomas Munro | 2026-04-04 01:07:04 | Re: pg_waldump: support decoding of WAL inside tarfile |