public inbox for [email protected]
help / color / mirror / Atom feedFrom: Masahiko Sawada <[email protected]>
To: Daniil Davydov <[email protected]>
Cc: SATYANARAYANA NARLAPURAM <[email protected]>
Cc: Bharath Rupireddy <[email protected]>
Cc: Sami Imseih <[email protected]>
Cc: Alexander Korotkov <[email protected]>
Cc: Matheus Alcantara <[email protected]>
Cc: Maxim Orlov <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: POC: Parallel processing of indexes in autovacuum
Date: Tue, 7 Apr 2026 00:48:46 -0700
Message-ID: <CAD21AoDEfe5-tYSqa=MGLP5TX5QH2irVZVyULCeTQj0J92Hp1A@mail.gmail.com> (raw)
In-Reply-To: <CAJDiXggvE=e=0+HnZ1XjwUcXYTb0dw77pRUts5gqY997YaxVjQ@mail.gmail.com>
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>
<[email protected]>
<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>
<CAD21AoA0bnRZC_OqKMnH-Ln+OZ9z9k56j2c_MXj8pw69O-wkBw@mail.gmail.com>
<CAA5RZ0sSXDza7_nUUbhHL_Sws+M+HR1daKJPXHpdLuNCkwUgUg@mail.gmail.com>
<CAJDiXggrBsbzOisf+Nu8pZkYGrpUZaFbosL1Wbm3kKxzTm4xgw@mail.gmail.com>
<CAA5RZ0tbiPcgQEjnhdnjz6qSjfRsGrr8jGCaMcrMaoPpax3wig@mail.gmail.com>
<CAJDiXgjt5ZmK2uvS0E8Ztt5ePYmq8Ze_dG05Zo2NUsKLHCEuYA@mail.gmail.com>
<CAD21AoB7v5tLPXLK=qmtt6PaEC1f+Fb-gh+MwAbXfm6x4eZGNw@mail.gmail.com>
<CAJDiXghwtUbiFnAh3nSaxTk8KFupQuMbp+g4z3wOLoQfMuqgDg@mail.gmail.com>
<CAJDiXgjoNd4BF19HNY_FAcDUqiqsfw8cGhNOJwBxahB8P38E3Q@mail.gmail.com>
<CAD21AoBT1LWqPZkcHpVMVh0ZOXUneO=p61t0i8cQ+kOP9qfODQ@mail.gmail.com>
<CAJDiXggL=J0nV7PfBsMW9+UOU3KUp1jNBM9Gov1JvAX7aG_U1g@mail.gmail.com>
<CAD21AoDz-1Zf9DOJJrdcB2=eNA4UdywthkowNp_dHmOGC-yV_g@mail.gmail.com>
<CAJDiXgjzphJ313=aDwbvryHpmTi6AqE+-5crysTtzKv01-vkzA@mail.gmail.com>
<CAD21AoD7_4gsQ2a82zO3SaRwjdw_3tyiYDHNFPUKQ5DAA5HOtA@mail.gmail.com>
<CAJDiXggY1QzNde6_HhpzneLc9dYqmWZ+PY39cuBXYdcCTuoJBA@mail.gmail.com>
<CAD21AoCFPiS2jcMA1JaV1kT8xrGz5BpN7iBP_gCgRuaANEbciA@mail.gmail.com>
<CAJDiXgh6jmNGR3uOB_6YeGhNkR2=HdTdEYjmHXdumNzyY4MckQ@mail.gmail.com>
<CAD21AoDs3SOXeAEoCRizfEKybpRkE7t7poX0+iZ6MM1MFWMsfA@mail.gmail.com>
<CAJDiXgjTkuqSPerC_nasxDz6d2Komf1ipYKV6SupDRnc9yhO9w@mail.gmail.com>
<CAD21AoAXMjX03h5K84u0heBLU+fqGgWBGBDwnBDGSs=DhyF9pQ@mail.gmail.com>
<CAJDiXghjZEAYboGhujgGvY9=RiFD01ERHVVF+NQMuuAKVZDmDQ@mail.gmail.com>
<CAD21AoAD+N5SxBr0qL7TeWnvq4iYmFT=DyWdNLQPB-XntYkwEg@mail.gmail.com>
<CAJDiXgjgn87sH1-MmONPKkeYJG83C0ChrYkYn9UcRonLhOOfOw@mail.gmail.com>
<CAD21AoCoJYauWO78M-CGdHpYfcqEZVV5a1Z-7wWB=-G-x8EVFg@mail.gmail.com>
<CAJDiXghaazbrQMZZS08d9Ffh2y4w05TgH9dpBhqChv1qNTp+xA@mail.gmail.com>
<CAD21AoDbaNtLrFRxG9OG5WrBd7DCs4q+CfJd8AJTBEqRri4WeQ@mail.gmail.com>
<CAJDiXgjjd1jL86B--AyRo2tDM1Wiu+7Pduwh5d0u_UM8GRugvw@mail.gmail.com>
<CAD21AoBo_wS7y0X7_7ajEFkptzo9ZrF8RFNRnu2Xe8XL74o0SQ@mail.gmail.com>
<CAJDiXggH1bW=4n+55CGLvs_sRU4SYNXwYLZ37wvJ5H_3yURSPw@mail.gmail.com>
<CAD21AoDxhN8Z6Lx1ZicBXKkbMsRQqEXiq4ALs4uaD648iSvXoA@mail.gmail.com>
<CAJDiXgh3Dg2f5k3xRJnzoY39jQENUhh125ArYapXkSu5D7JJuw@mail.gmail.com>
<CAD21AoBYc7L7W4dRdxeoJzOH5OgpiCAtKz-54iX4Ufn8PnQoww@mail.gmail.com>
<CAJDiXgi8X-DMb92v5WHLCNxDHxH9gO8WQxOMtdpmU7X=WXCiuQ@mail.gmail.com>
<CAD21AoDKxs0UrTwa3rkP+kE9AzccabpK7G-Tk=HYneaFTZBtiA@mail.gmail.com>
<CALj2ACUJ0TtYWtFuXXVf0aLES8tfZePXnB8WQ=0KCrNaABzQVg@mail.gmail.com>
<CAJDiXgj=-R1z7H7+npm-o+q6YBkr5_6Qe=1wcy47ovAqej4TkA@mail.gmail.com>
<CAHg+QDehxaJEd1Yp1MpW8UO71xmbasy7t2GZGvqOYwkr0md8DQ@mail.gmail.com>
<CAJDiXgi73x7h0=UoXriFjskRB6htZ-uqXKqvWN3RefuxbP93gA@mail.gmail.com>
<CAJDiXghbc38pMFCNNbVx1N=6ZKdsO5u3SF8pZrKm2mJvX71OKw@mail.gmail.com>
<CAD21AoAqkBtCYwuwbiJ6qA+Ny-pO4idpfgqZBDxE6tGgHTpm1A@mail.gmail.com>
<CAJDiXgj3A=wNC-S0z3TixmnVUkifs=07yLLHJ7_+dDsakft1tA@mail.gmail.com>
<CAD21AoAvZc6Rwi1hZ7x+U3vz7AMMSpcbQ2JBn6+WmQp-3yfKMg@mail.gmail.com>
<CAJDiXggvE=e=0+HnZ1XjwUcXYTb0dw77pRUts5gqY997YaxVjQ@mail.gmail.com>
On Wed, Apr 1, 2026 at 12:44 AM Daniil Davydov <[email protected]> wrote:
> >
> > > 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.
> >
> > I'm still struggling to see the technical justification; why would a
> > user want to avoid parallel vacuuming on eligible tables if they have
> > already explicitly allowed the system to use more resources by setting
> > autovacuum_max_parallel_workers to >0?
>
> Here I am talking about "introductory data". I.e. the situation that the user
> has before considering our parameter usage. Based on this situation, it seems
> to me that not everyone will want to turn on parallel a/v (because of resource
> shortage hazard).
>
> > If resource contention occurs,
> > it is typically a sign that the global parameters need re-tuning. As I
> > mentioned, the same contention can occur even with an opt-in style if
> > multiple tables are manually configured.
> >
>
> Yep, we already discussed it and I agree with you. I think that in the case of
> opt-in style the resource contention will be much more controlled. But actually
> the opt-in style in the form in which I originally proposed it, no longer seems
> like a good idea to me. Classic opt-in style will deprive us of support for
> half of the parallel a/v use cases. Anton's proposal seems to me like a good
> balance between the two styles.
>
> > > 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.
> >
> > While some autovacuum parameters do override GUCs, those are typically
> > local to the process (like cost delay). Parallel workers, however, are
> > a shared system-wide resource. In a multi-tenant environment, allowing
> > a single table's reloption to bypass the
> > autovacuum_max_parallel_workers = 0 limit could lead to unexpected
> > exhaustion of the worker pool.
>
> Will this exhaustion really be unexpected? If we describe such an ability in
> the documentation, and the user uses it, then everything is fair. Even if
> administrator forgets that he enabled av_parallel_workers reloption somewhere,
> then he can :
How can DBAs prevent parallel workers from being exhaustly used if
users set a high value to the reloption?
> 1)
> Check the logfile (if log level is not too high) searching for logs like
> "parallel workers: index vacuum: N planned, N launched in total".
> 2)
> Run a query that selects all tables which have av_parallel_workers > 0.
Does that mean DBAs would need to run these queries periodically? I
don't think that in a multi-tenant environment, DBAs can (or should)
execute ALTER TABLE on user-owned tables just to fix resource issues.
>
> >I think that this GUC should act as a
> > reliable global switch for resource management.
>
> I agree that the "global switch" is an attractive idea and we should strive
> for it. But our parameter *can* play the role of the switch if users don't
> manually touch the av_parallel_workers reloption. But if they do - well, it is
> their responsibility to turn the reloption off.
>
> >
> > > 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.
> >
> > I'm not prioritizing one specific use case over another. I believe
> > that there are also users who want to use parallel vacuum on hundreds
> > of thousands of tables. We should consider a better solution while
> > checking it from multiple perspectives such as the usability, the
> > robustness and consistency with the existing features and behaviors
> > etc.
>
> For those users who want to use parallel a/v for hundreds of thousands of
> tables we have the default value "-1" which allows parallel a/v everywhere via
> GUC parameter manipulation.
>
> For those users who want to parallel a/v on several specific tables we can
> allow setting reloption that will override the GUC.
>
> I guess that the question is : "Is it normal if the GUC parameter will lose
> ability to turn off parallel a/v everywhere after the user has manually raised
> the value for the av_parallel_workers reloption on a few tables?". If the
> answer is "Yes", I don't see any obstacles for us to allow overriding the GUC
> parameter via reloption.
I think the answer is no, particularly for this parameter. Since it
controls a system-wide shared resource, it should be capped by a GUC
to ensure centralized management, consistent with other
parallel-query-related GUCs and reloptions.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
view thread (112+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: POC: Parallel processing of indexes in autovacuum
In-Reply-To: <CAD21AoDEfe5-tYSqa=MGLP5TX5QH2irVZVyULCeTQj0J92Hp1A@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox