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

From Andrew Borodin
Subject Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree
Date
Msg-id CAJEAwVFAwTRh+D-3wZLj-4hjkrguRrFqA1C_P569OpzhgmHyBA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
Hi, Teodor!

2017-03-21 20:32 GMT+05:00 Teodor Sigaev <teodor@sigaev.ru>:
> I had a look on patch

That's great, thanks!

>
>         /*
>          * 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.

No, second conditional code will be called for any subtree, which
contains totally empty subtree. That check !isRoot covers case when
the entire posting tree should be erased: we cannot just quit out of
recursive cleanup, we have to make a scan here, starting from root.

Probably, variable isChildHasVoid has a bit confusing name. This flag
indicates that some subtree:
1. Had empty pages
2. Did not bother deleting them, because there is a chance that it is
a part of a bigger empty subtree.
May be it'd be better to call the variable "someChildIsVoidSubtree".

>just remove lock for cleanup over ginVacuumPostingTreeLeaves() and if it returns that tree contains empty page then
lockthe whole posting tree to do ginScanToDelete() work.
 

It is, indeed, viable approach. But currently proposed patch is
capable of dealing with small page deletes without much of locking
fuss, even in 4-5 level trees.

How do you think, which way should we take?

Best regards, Andrey Borodin.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] logical replication apply to run with sync commit off by default
Next
From: David Steele
Date:
Subject: Re: [HACKERS] PATCH: Configurable file mode mask