MIME-Version: 1.0
References: 
 <CACG=ezZOrNsuLoETLD1gAswZMuH2nGGq7Ogcc0QOE5hhWaw=cw@mail.gmail.com>
 <CAD21AoCdx5ZNS_cO7bYz1Zfb+Kw1kuJV2wtewrz7T1pPpjcWGw@mail.gmail.com>
 <CAJDiXgi6ZQOoSEqj9RyZMEh+HHBtmW0+PHD85UNPtKch8ubvdg@mail.gmail.com>
 <CAD21AoBcoA-i-pJ_=y+jg14R8_QaJA1iwktCnu5i-C=yXDFPdA@mail.gmail.com>
 <CAJDiXgjnUdE6Sk4M0unmT+9dULyFAxcum2txQKpWTuo4uQ_oXQ@mail.gmail.com>
 <CAD21AoBTZdVR93JBo620B=MX-K8cdm3VRbjrBr_Vcpngk3AjVw@mail.gmail.com>
 <CAA5RZ0vfBg=c_0Sa1Tpxv8tueeBk8C5qTf9TrxKBbXUqPc99Ag@mail.gmail.com>
 <CAD21AoBgvUeWS8ZsXBahA1XdYayK6DJ6dx49d6Xpii-iH+Hrwg@mail.gmail.com>
 <CAA5RZ0vF+Lr-jU1LAZWTGUjboUETk8oLvaNBbA5ozX6dau+how@mail.gmail.com>
 <CAJDiXggueLSGMNRmLshbmFRfbo4jzks0W8bLDfUSRZ-61fPVEQ@mail.gmail.com>
 <CAFY6G8cJ=DRTX75pOGerH6sk39dRt+7MSH+y_qppDdhPs=qdQA@mail.gmail.com>
 <CAJDiXgg1t6wk9NjyMUTm1iKqM9GtdQ_wrEchBtz3xjWBZM8W8A@mail.gmail.com>
 <CAD21AoAC0=Xi38RQcAO4A+vdmoXToZMoHfbS=KLT49fAOTH_gA@mail.gmail.com>
 <CAJDiXgiD+AZKhJSn-FSRVQxtDLmJd95wDu4wtKniQF5==1JcjQ@mail.gmail.com>
 <CAD21AoAM8KsqNhrZYJuf7odvxcTC0TumXazJc-r_wC5KnDFDPg@mail.gmail.com>
 <CAJDiXghbcOC9OOj3ampxuyqXH0geggnosnrYUHGygkpss-RtxA@mail.gmail.com>
 <CAD21AoAPnq0vrcGgeN++r1GoL8Kza7jaGL=TNzuBn6+MkR=rUQ@mail.gmail.com>
 <CAJDiXghmsbTmnm--9B5bbuZXa1OL7SZ0HYppX3tx9XsdwfJBhA@mail.gmail.com>
 <DB3C67FCRLOO.1R5NLYCNEA6BF@gmail.com>
 <CAJDiXgiYiX+azuR76DcVx8fZn57m_4v6cB14-GW34mWa=qudFQ@mail.gmail.com>
 <CAD21AoDtPpkkQ_h1yf4oTx1qn4SRdTeVY3qs+9J07fYqa_4Gww@mail.gmail.com>
 <CAJDiXgi7KB7wSQ=Ux=ngdaCvJnJ5x-ehvTyiuZez+5uKHtV6iQ@mail.gmail.com>
 <CAD21AoCcHKKXsr9Oh736ejckqqS1i430xGEyJ=JP5OL0ExyP1A@mail.gmail.com>
 <CAJDiXghaFT_1sSv3q8mjyZ_RLZDgiogg0mWRvLxSWvkUi2CcLg@mail.gmail.com>
 <CAA5RZ0u63W41OmcEO+HLs4CSo-Sd3J+Q-4=04iud8V=xX4iUrA@mail.gmail.com>
 <CAJDiXgin1TXniVGJKzOTA=F9K342uVfm6O0EmubTVB=F+XSrbA@mail.gmail.com>
 <CAD21AoDadzAwibxf-+urjx=XL+eVu8=Ut-Lh2GxXUt32LbPG3Q@mail.gmail.com>
 <CAD21AoD6HhraqhOgkQJOrr0ixZkAZuqJRpzGv-B+_-ad6d5aPw@mail.gmail.com>
 <CAJDiXgiGSpqMQSOx-cVO_LtcB5GWHBy9ph7oOR4ebbX8A==kgw@mail.gmail.com>
 <CAD21AoBRRXbNJEvCjS-0XZgCEeRBzQPKmrSDjJ3wZ8TN28vaCQ@mail.gmail.com>
 <CAPpHfduBJfMcojvmYHUo8b_C=0cxRy1N+tNiNGoA3RAZq2ApaA@mail.gmail.com>
 <CAD21AoC82NeHKXc965pPUZO2eyo1U7P6cmfRJbrcPDcnd7_6hw@mail.gmail.com>
 <CAJDiXghP2kXnEz+cj3rAWNM3NdKSB_4WtnngFXpVz2omPhGr5A@mail.gmail.com>
In-Reply-To: 
 <CAJDiXghP2kXnEz+cj3rAWNM3NdKSB_4WtnngFXpVz2omPhGr5A@mail.gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Fri, 31 Oct 2025 13:03:14 -0700
Message-ID: 
 <CAD21AoA0bnRZC_OqKMnH-Ln+OZ9z9k56j2c_MXj8pw69O-wkBw@mail.gmail.com>
Subject: Re: POC: Parallel processing of indexes in autovacuum
To: Daniil Davydov <3danissimo@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
 Sami Imseih <samimseih@gmail.com>,
	Matheus Alcantara <matheusssilv97@gmail.com>,
 Maxim Orlov <orlovmg@gmail.com>,
	Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAD21AoA0bnRZC_OqKMnH-Ln%2BOZ9z9k56j2c_MXj8pw69O-wkBw%40mail.gmail.com>
Precedence: bulk

On Tue, Oct 28, 2025 at 6:10=E2=80=AFAM Daniil Davydov <3danissimo@gmail.co=
m> wrote:
>
> >
> > IIUC the patch still has one problem in terms of reloading the
> > configuration parameters during parallel mode as I mentioned
> > before[1].
> >
>
> Yep. I was happy to see that you think that config file processing is OK =
for
> autovacuum :)
> I'll allow it for a/v leader. I've also thought about "compute_parallel_d=
elay".
> The simplest solution that I see is to move cost-based delay parameters t=
o
> shared state (PVShared) and create some variables such a
> VacuumSharedCostBalance, so we can use them inside vacuum_delay_point.
> What do you think about this idea?

I think that we need to somehow have parallel workers use the new
vacuum delay parameters (e.g., VacuumCostPageHit and
VacuumCostPageMiss) after the leader reloads the configuration file.
The leader shares the initial parameters with the parallel workers
(via DSM) before starting the workers but doesn't propagate the
updates during the parallel operations. And the worker doesn't reload
the configuration file.

>
> Another approaches like a "tell parallel workers that they should
> reload config"
> looks a bit too invasive IMO.
>
>
> Thanks everybody for the review! Please, see v12 patches :
> 1) Implement tests for parallel autovacuum
> 2) Fix error with unreleased workers - see try/catch block in do_autovacu=
um
> and before_shmem_exit callback registration in AutoVacWorkerMain
> 3) Allow a/v leader to process config file (see guc.c)
>

Here are some review comments for 0001 patch:

+static void
+autovacuum_worker_before_shmem_exit(int code, Datum arg)
+{
+        if (code !=3D 0)
+                AutoVacuumReleaseAllParallelWorkers();
+}
+

AutoVacuumReleaseAllParallelWorkers() calls
AutoVacuumReleaseParallelWorkers() only when av_nworkers_reserved > 0,
so I think we don't need the condition 'if (code !=3D 0)' here.

---
 +extern void AutoVacuumReleaseAllParallelWorkers(void);

There is no caller of this function outside of autovacuum.h.

---
{ name =3D> 'autovacuum_max_parallel_workers', type =3D> 'int', context =3D=
>
'PGC_SIGHUP', group =3D> 'VACUUM_AUTOVACUUM',
  short_desc =3D> 'Maximum number of parallel autovacuum workers, that
can be taken from bgworkers pool.',
  long_desc =3D> 'This parameter is capped by "max_worker_processes"
(not by "autovacuum_max_workers"!).',
  variable =3D> 'autovacuum_max_parallel_workers',
  boot_val =3D> '0',
  min =3D> '0',
  max =3D> 'MAX_BACKENDS',
},

Parallel vacuum in autovacuum can be used only when users set the
autovacuum_parallel_workers storage parameter. How about using the
default value 2 for autovacuum_max_parallel_workers GUC parameter?

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com