On Wed, Oct 9, 2019 at 6:13 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Sat, Oct 5, 2019 at 4:36 PM Dilip Kumar <dilipbal...@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
