On Tue, Nov 12, 2019 at 5:30 PM Masahiko Sawada <masahiko.saw...@2ndquadrant.com> wrote: > > On Tue, 12 Nov 2019 at 20:11, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Tue, Nov 12, 2019 at 3:39 PM Masahiko Sawada > > <masahiko.saw...@2ndquadrant.com> wrote: > > > > > > On Tue, 12 Nov 2019 at 18:26, Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > > > > > On Tue, Nov 12, 2019 at 2:25 PM Amit Kapila <amit.kapil...@gmail.com> > > > > wrote: > > > > > > > > > > Yeah, maybe something like amparallelvacuumoptions. The options can > > > > > be: > > > > > > > > > > VACUUM_OPTION_NO_PARALLEL 0 # vacuum (neither bulkdelete nor > > > > > vacuumcleanup) can't be performed in parallel > > > > > VACUUM_OPTION_NO_PARALLEL_CLEANUP 1 # vacuumcleanup cannot be > > > > > performed in parallel (hash index will set this flag) > > > > > > > > Maybe we don't want this option? because if 3 or 4 is not set then we > > > > will not do the cleanup in parallel right? > > > > > > > > Yeah, but it is better to be explicit about this. > > VACUUM_OPTION_NO_PARALLEL_BULKDEL is missing? >
I am not sure if that is required. > I think brin indexes > will use this flag. > Brin index can set VACUUM_OPTION_PARALLEL_CLEANUP in my proposal and it should work. > It will end up with > (VACUUM_OPTION_NO_PARALLEL_CLEANUP | > VACUUM_OPTION_NO_PARALLEL_BULKDEL) is equivalent to > VACUUM_OPTION_NO_PARALLEL, though. > > > > > > > > VACUUM_OPTION_PARALLEL_BULKDEL 2 # bulkdelete can be done in > > > > > parallel (Indexes nbtree, hash, gin, gist, spgist, bloom will set this > > > > > flag) > > > > > VACUUM_OPTION_PARALLEL_COND_CLEANUP 3 # vacuumcleanup can be done in > > > > > parallel if bulkdelete is not performed (Indexes nbtree, brin, hash, > > > > > gin, gist, spgist, bloom will set this flag) > > > > > VACUUM_OPTION_PARALLEL_CLEANUP 4 # vacuumcleanup can be done in > > > > > parallel even if bulkdelete is already performed (Indexes gin, brin, > > > > > and bloom will set this flag) > > > > > > > > > > Does something like this make sense? > > > > > > 3 and 4 confused me because 4 also looks conditional. How about having > > > two flags instead: one for doing parallel cleanup when not performed > > > yet (VACUUM_OPTION_PARALLEL_COND_CLEANUP) and another one for doing > > > always parallel cleanup (VACUUM_OPTION_PARALLEL_CLEANUP)? > > > > > > > Hmm, this is exactly what I intend to say with 3 and 4. I am not sure > > what makes you think 4 is conditional. > > Hmm so why gin and bloom will set 3 and 4 flags? I thought if it sets > 4 it doesn't need to set 3 because 4 means always doing cleanup in > parallel. > Yeah, that makes sense. They can just set 4. > > > > > That way, we > > > can have flags as follows and index AM chooses two flags, one from the > > > first two flags for bulk deletion and another from next three flags > > > for cleanup. > > > > > > VACUUM_OPTION_PARALLEL_NO_BULKDEL 1 << 0 > > > VACUUM_OPTION_PARALLEL_BULKDEL 1 << 1 > > > VACUUM_OPTION_PARALLEL_NO_CLEANUP 1 << 2 > > > VACUUM_OPTION_PARALLEL_COND_CLEANUP 1 << 3 > > > VACUUM_OPTION_PARALLEL_CLEANUP 1 << 4 > > > > > > > This also looks reasonable, but if there is an index that doesn't want > > to support a parallel vacuum, it needs to set multiple flags. > > Right. It would be better to use uint16 as two uint8. I mean that if > first 8 bits are 0 it means VACUUM_OPTION_PARALLEL_NO_BULKDEL and if > next 8 bits are 0 means VACUUM_OPTION_PARALLEL_NO_CLEANUP. Other flags > could be followings: > > VACUUM_OPTION_PARALLEL_BULKDEL 0x0001 > VACUUM_OPTION_PARALLEL_COND_CLEANUP 0x0100 > VACUUM_OPTION_PARALLEL_CLEANUP 0x0200 > Hmm, I think we should define these flags in the most simple way. Your previous proposal sounds okay to me. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
