On Tue, Mar 19, 2019 at 7:29 PM Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > > At Tue, 19 Mar 2019 17:51:32 +0900, Masahiko Sawada <sawada.m...@gmail.com> > wrote in <cad21aocuzqmyxrwdw57ejor-j1qrgqm_vrqkokif_ajk4gi...@mail.gmail.com> > > On Tue, Mar 19, 2019 at 10:39 AM Haribabu Kommi > > <kommi.harib...@gmail.com> wrote: > > > The performance results are good. Do we want to add the recommended > > > size in the document for the parallel option? the parallel option for > > > smaller > > > tables can lead to performance overhead. > > > > > > > Hmm, I don't think we can add the specific recommended size because > > the performance gain by parallel lazy vacuum depends on various things > > such as CPU cores, the number of indexes, shared buffer size, index > > types, HDD or SSD. I suppose that users who want to use this option > > have some sort of performance problem such as that vacuum takes a very > > long time. They would use it for relatively larger tables. > > Agree that we have no recommended setting, but I strongly think that > documentation on the downside or possible side effect of this feature is > required for those who are to use the feature. >
I think that the side effect of parallel lazy vacuum would be to consume more CPUs and I/O bandwidth, but which is also true for the other utility command (i.e. parallel create index). The description of max_parallel_maintenance_worker documents such things[1]. Anything else to document? [1] https://www.postgresql.org/docs/devel/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-ASYNC-BEHAVIOR Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
