Re: POC: Parallel processing of indexes in autovacuum
От | Daniil Davydov |
---|---|
Тема | Re: POC: Parallel processing of indexes in autovacuum |
Дата | |
Msg-id | CAJDiXgjX+bO=dEZxpnsh588N3BsQ=7MHX3YQSJS6FxqGq4zMqQ@mail.gmail.com обсуждение исходный текст |
Ответ на | POC: Parallel processing of indexes in autovacuum (Maxim Orlov <orlovmg@gmail.com>) |
Список | pgsql-hackers |
Hi, On Tue, Jul 8, 2025 at 10:20 PM Matheus Alcantara <matheusssilv97@gmail.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
В списке pgsql-hackers по дате отправления: