| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Daniil Davydov <3danissimo(at)gmail(dot)com> |
| Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(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-03-25 22:42:30 |
| Message-ID: | CAD21AoDKxs0UrTwa3rkP+kE9AzccabpK7G-Tk=HYneaFTZBtiA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 25, 2026 at 12:45 AM Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:
>
> Hi,
>
> > > Yeah, currently user can misconfigure max_parallel_workers, so (for example)
> > > multiple VACUUM PARALLEL operations running at the same time will face with
> > > a shortage of parallel workers. But I guess that every system has some sane
> > > limit for this parameter's value. If we want to ensure that all a/v leaders
> > > are guaranteed to launch as many parallel workers as required, we might need
> > > to increase the max_parallel_workers too much (and cross the sane limit).
> > > IMHO it may be unacceptable for many systems in production, because it will
> > > undermine the stability.
> >
> > I understand the concern that if max_parallel_workers (and/or
> > max_worker_processes) value are not high enough to ensure each
> > autovacuum workers can launch autovacuum_max_parallel_workers, an
> > autovacuum on the very large table might not be able to launch the
> > full workers in case where some parallel workers are already being
> > used by others (e.g., another autovacuum on a different
> > slightly-smaller table etc.). But I'm not sure that the opt-out style
> > can handle these cases. Even if there are two huge tables and users
> > set parallel_vacuum_workers to both tables, there is no guarantee that
> > autovacuums on these tables can use the full workers, as long as
> > max_parallel_workers value is not enough.
> >
>
> I guess you mean the "opt-in" style here?
Oops, yes. I wanted it to mean "opt-in" style.
>
> Sure, even opt-in style doesn't give us an unbreakable guarantee that huge
> tables will be processed with the desired number of parallel workers. But IMHO
> "opt-in" greatly increases the probability of this.
Cost-based vacuum delay parameters shared between the autovacuum
leader and its parallel workers.
> Searching for arguments in
> favor of opt-in style, I asked for help from another person who has been
> managing the setup of highload systems for decades. He promised to share his
> opinion next week.
Given that we have one and half weeks before the feature freeze, I
think it's better to complete the project first before waiting for
his/her comments next week. Even if we finish this feature with the
opt-out style, we can hear more opinions on it and change the default
behavior as the change would be privial. What do you think?
I've squashed all patches except for the documentation patch as I
assume you're working on it. The attached fixup patch contains several
changes: using opt-out style, comment improvements, and fixing typos
etc.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
| Attachment | Content-Type | Size |
|---|---|---|
| v31-0002-fixup-several-changes.patch | text/x-patch | 13.5 KB |
| v31-0001-Parallel-autovacuum.patch | text/x-patch | 31.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Jones | 2026-03-25 23:00:02 | Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables |
| Previous Message | Matthias van de Meent | 2026-03-25 22:42:01 | Re: SQL-level pg_datum_image_equal |