Re: Review: GIN non-intrusive vacuum of posting tree

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: amborodin(at)acm(dot)org, Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Vladimir Borodin <root(at)simply(dot)name>
Subject: Re: Review: GIN non-intrusive vacuum of posting tree
Date: 2017-03-21 15:32:21
Message-ID: 6f762594-5261-08e7-663d-97b82ccd0942@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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. Unless we 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2017-03-21 15:45:54 Re: [PATCH] kNN for SP-GiST
Previous Message Tom Lane 2017-03-21 15:31:08 Re: WIP: Faster Expression Processing v4