Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers
От | Robert Haas |
---|---|
Тема | Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers |
Дата | |
Msg-id | CA+TgmoYiP8ehDUCVf1=eeEUQOgJp55jK2YsvsC9CVXnONb9tXg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Ответы |
Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers
|
Список | pgsql-hackers |
On Sat, Oct 3, 2020 at 9:25 AM Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote: > To make the behavior of parallel vacuum more consistent with other > parallel maintenance commands (i.g., only parallel INDEX CREATE for > now), as a second idea, can we make use of parallel_workers reloption > in parallel vacuum case as well? That seems like a terrible idea to me. I don't see why the number of workers that some user thinks should be used to perform a scan on the table as part of the query should be the same as the number of workers that should be used for a maintenance operation. We get in trouble every time we try to reuse a setting for an unrelated purpose. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: