On Mon, Nov 18, 2019 at 11:37 AM Masahiko Sawada <masahiko.saw...@2ndquadrant.com> wrote: > > On Wed, 13 Nov 2019 at 14:31, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > Based on these needs, we came up with a way to allow users to specify > > this information for IndexAm's. Basically, Indexam will expose a > > variable amparallelvacuumoptions which can have below options > > > > VACUUM_OPTION_NO_PARALLEL 1 << 0 # vacuum (neither bulkdelete nor > > vacuumcleanup) can't be performed in parallel > > I think VACUUM_OPTION_NO_PARALLEL can be 0 so that index AMs who don't > want to support parallel vacuum don't have to set anything. >
make sense. > > VACUUM_OPTION_PARALLEL_BULKDEL 1 << 1 # bulkdelete can be done in > > parallel (Indexes nbtree, hash, gin, gist, spgist, bloom will set this > > flag) > > VACUUM_OPTION_PARALLEL_COND_CLEANUP 1 << 2 # vacuumcleanup can be > > done in parallel if bulkdelete is not performed (Indexes nbtree, brin, > > gin, gist, > > spgist, bloom will set this flag) > > VACUUM_OPTION_PARALLEL_CLEANUP 1 << 3 # vacuumcleanup can be done in > > parallel even if bulkdelete is already performed (Indexes gin, brin, > > and bloom will set this flag) > > I think gin and bloom don't need to set both but should set only > VACUUM_OPTION_PARALLEL_CLEANUP. > > And I'm going to disallow index AMs to set both > VACUUM_OPTION_PARALLEL_COND_CLEANUP and VACUUM_OPTION_PARALLEL_CLEANUP > by assertions, is that okay? > Sounds reasonable to me. Are you planning to include the changes related to I/O throttling based on the discussion in the nearby thread [1]? I think you can do that if you agree with the conclusion in the last email[1], otherwise, we can explore it separately. [1] - https://www.postgresql.org/message-id/CAA4eK1%2BuDgLwfnAhQWGpAe66D85PdkeBygZGVyX96%2BovN1PbOg%40mail.gmail.com -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
