Re: [HACKERS] Block level parallel vacuum
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] Block level parallel vacuum |
Дата | |
Msg-id | CAA4eK1+H_7URPmQvYKTYfKvDADaJn6x764f+DC+P9NEqp1ZMgQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Block level parallel vacuum (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
On Wed, Oct 9, 2019 at 6:13 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Sat, Oct 5, 2019 at 4:36 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > 3. > > @@ -2888,6 +2888,8 @@ table_recheck_autovac(Oid relid, HTAB *table_toast_map, > > (!wraparound ? VACOPT_SKIP_LOCKED : 0); > > tab->at_params.index_cleanup = VACOPT_TERNARY_DEFAULT; > > tab->at_params.truncate = VACOPT_TERNARY_DEFAULT; > > + /* parallel lazy vacuum is not supported for autovacuum */ > > + tab->at_params.nworkers = -1; > > > > What is the reason for the same? Can we explain in the comments? > > I think it's just that we don't want to support parallel auto vacuum > because it can consume more CPU resources in spite of background job, > which might be an unexpected behavior of autovacuum. > I think the other reason is it can generate a lot of I/O which might choke other operations. I think if we want we can provide Guc(s) to control such behavior, but initially providing it via command should be a good start so that users can knowingly use it in appropriate cases. We can later extend it for autovacuum if required. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: