Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree
Date
Msg-id 6f762594-5261-08e7-663d-97b82ccd0942@sigaev.ru
Whole thread Raw
In response to Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree  (Andrew Borodin <borodin@octonica.com>)
Responses Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree  (Andrew Borodin <borodin@octonica.com>)
List pgsql-hackers
> Thank you for your suggestions, do not hesitate to ask any questions,
> concurrency and GIN both are very interesting topics.

I had a look on patch and found some issue.
Look at ginvacuum.c around line 387, function ginVacuumPostingTreeLeaves():

        /*         * All subtree is empty - just return TRUE to indicate that parent must         * do a cleanup.
Unlesswe are ROOT an there is way to go upper.         */
 
        if(isChildHasVoid && !isAnyNonempy && !isRoot)            return TRUE;
        if(isChildHasVoid)        {    ...    ginScanToDelete(gvs, blkno, TRUE, &root, InvalidOffsetNumber);}

In first 'if' clause I see !isRoot, so second if and corresponding 
ginScanToDelete() could be called only for root in posting tree. If so, it seems 
to me, it wasn't a good idea to move ginScanToDelete() from
ginVacuumPostingTree() and patch should just remove lock for cleanup over 
ginVacuumPostingTreeLeaves() and if it returns that tree contains empty page 
then lock the whole posting tree to do ginScanToDelete() work.



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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] WIP: Faster Expression Processing v4
Next
From: David Steele
Date:
Subject: Re: [HACKERS] [PATCH] kNN for SP-GiST