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>
In-Reply-To: 
 <CAA5RZ0vfBg=c_0Sa1Tpxv8tueeBk8C5qTf9TrxKBbXUqPc99Ag@mail.gmail.com>
From: Daniil Davydov <3danissimo@gmail.com>
Date: Tue, 6 May 2025 12:16:06 +0700
Message-ID: 
 <CAJDiXgiPOxFyEyJC4C4nWu2iuaBeeT4e32dbERMWA9fpWMQXvQ@mail.gmail.com>
Subject: Re: POC: Parallel processing of indexes in autovacuum
To: Sami Imseih <samimseih@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@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/CAJDiXgiPOxFyEyJC4C4nWu2iuaBeeT4e32dbERMWA9fpWMQXvQ%40mail.gmail.com>
Precedence: bulk

On Tue, May 6, 2025 at 7:21=E2=80=AFAM Sami Imseih <samimseih@gmail.com> wr=
ote:
>
> Perhaps we should only provide a reloption, therefore only tables specifi=
ed
> by the user via the reloption can be autovacuumed  in parallel?

=D0=90fter your comments (earlier in this thread) I decided to do just
that. For now we have reloption, so the user can decide which tables
are "important" for parallel index vacuuming.
We also set lower bounds (hardcoded) on the number of indexes and the
number of dead tuples. For example, there is no need to use a parallel
vacuum if the table has only one index.
The situation is more complicated with the number of dead tuples - we
need tests that would show the optimal minimum value. This issue is
still being worked out.

> This gives a targeted approach. Of course if multiple of these allowed ta=
bles
> are to be autovacuumed at the same time, some may not get all the workers=
,
> But that=E2=80=99s not different from if you are to manually vacuum in pa=
rallel the tables
> at the same time.

I fully agree. Recently v2 patch has been supplemented with a new
feature [1] - multiple tables in a cluster can be processed in
parallel during autovacuum. And of course, not every a/v worker can
get enough supportive processes, but this is considered normal
behavior.
Maximum number of supportive workers is limited by the GUC variable.

[1] I guess that I'll send it within the v3 patch, that will also
contain logic that was discussed in the letter above - using bgworkers
instead of additional a/v workers. BTW, what do you think about this
idea?

--
Best regards,
Daniil Davydov