Re: [PATCHES] GIN improvements

> Well, if that is required to be true then this whole design is pretty
> broken, because VACUUM doesn't hold any lock that would guarantee that
> no insert happens between the two calls.  If we fold the two AM calls
> into one call then it'd be okay for the index AM to take such a lock
> transiently during the single index-cleanup-plus-bulkdelete call.
Actually, lock doesn't needed. Just bulkdelete should not try to remove not yet 
"insertcleanuped" items pointer. That's easy because VacPageList is prepared 
before insertcleanup call.


> Maybe it'd be better if ambulkdelete *did* scan the pending list?

I don't like that idea because it requires to add a lot of code (concurrent 
deletion of pages in list), much simpler to call insertcleanup inside 
ginbulkdelete/ginvacuumcleanup.

> You'd still need at least page-level locking but perhaps not anything
> stronger.

That's close to trivial to revert this piece to add cleanup call to 
ginbulkdelete/ginvacuumcleanup. Early variants used this variant.
Reasons for new variant was: - defining needing of call of insertcleanup, and stats argument was used for   it in both
function.If it's a NULL then call cleanup. - I thought about statistic-based trigger for separate call of
insertcleanup.  Trigger should be fired on massive insert/update events very similar to   trigger on massive delete for
ambulkdelete.I'm very sorry but I didn't do it   yet, and definitely I need some help here.
 

Do I revert that piece?

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/