On Wed, Nov 13, 2019 at 11:01 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Nov 13, 2019 at 9:48 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > Yeah, 0,2,3 and 4 sounds reasonable to me. Earlier, Dilip also got > > confused with option 1. > > > > Let me try to summarize the discussion on this point and see if others > have any opinion on this matter. > > We need a way to allow IndexAm to specify whether it can participate > in a parallel vacuum. As we know there are two phases of > index-vacuum, bulkdelete and vacuumcleanup and in many cases, the > bulkdelete performs the main deletion work and then vacuumcleanup just > returns index statistics. So, for such cases, we don't want the second > phase to be performed by a parallel vacuum worker. Now, if the > bulkdelete phase is not performed, then vacuumcleanup can process the > entire index in which case it is better to do that phase via parallel > worker. > > OTOH, in some cases vacuumcleanup takes another pass over-index to > reclaim empty pages and update record the same in FSM even if > bulkdelete is performed. This happens in gin and bloom indexes. > Then, we have an index where we do all the work in cleanup phase like > in the case of brin indexes. Now, for this category of indexes, we > want vacuumcleanup phase to be also performed by a parallel worker. > > In short different indexes have different requirements for which phase > of index vacuum can be performed in parallel. Just to be clear, we > can't perform both the phases (bulkdelete and cleanup) in one-go as > bulk-delete can happen multiple times on a large index whereas > vacuumcleanup is done once at the end. > > 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 > 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) > > We have discussed to expose this information via two variables but the > above seems like a better idea to all the people involved. > > Any suggestions? Anyone thinks this is not the right way to expose > this information or there is no need to expose this information or > they have a better idea for this? > > Sawada-San, Dilip, feel free to correct me. Looks fine to me.
-- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
