From: | Daniil Davydov <3danissimo(at)gmail(dot)com> |
---|---|
To: | Matheus Alcantara <matheusssilv97(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Sami Imseih <samimseih(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: | 2025-07-09 05:26:24 |
Message-ID: | CAJDiXgjX+bO=dEZxpnsh588N3BsQ=7MHX3YQSJS6FxqGq4zMqQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Tue, Jul 8, 2025 at 10:20 PM Matheus Alcantara
<matheusssilv97(at)gmail(dot)com> wrote:
>
> On Sun Jul 6, 2025 at 5:00 AM -03, Daniil Davydov wrote:
> > I will keep the 'max_worker_processes' limit, so autovacuum will not
> > waste time initializing a parallel context if there is no chance that
> > the request will succeed.
> > But it's worth remembering that actually the
> > 'autovacuum_max_parallel_workers' parameter will always be implicitly
> > capped by 'max_parallel_workers'.
> >
> > What do you think about it?
> >
>
> It make sense to me. The main benefit that I see on capping
> autovacuum_max_parallel_workers parameter is that users will see
> "invalid value for parameter "autovacuum_max_parallel_workers"" error on
> logs instead of need to search for "planned vs. launched", which can be
> trick if log_min_messages is not set to at least the info level (the
> default warning level will not show this log message).
>
I think I can refer to (for example) 'max_parallel_workers_per_gather'
parameter, which allows
setting values higher than 'max_parallel_workers' without throwing an
error or warning.
'autovacuum_max_parallel_workers' will behave the same way.
> If we decide to not cap this on code I think that at least would be good to mention this
> on documentation.
Sure, it is worth noticing in documentation.
--
Best regards,
Daniil Davydov
From | Date | Subject | |
---|---|---|---|
Next Message | suyu.cmj | 2025-07-09 05:51:03 | Re: The same 2PC data maybe recovered twice |
Previous Message | shveta malik | 2025-07-09 04:53:40 | Re: Improve pg_sync_replication_slots() to wait for primary to advance |