Re: Odd code around ginScanToDelete

On Thu, Mar 12, 2026 at 12:35 AM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
>
> On Thu, 12 Mar 2026 at 02:22, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> >
> > On Tue, Mar 10, 2026 at 11:29 AM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> > > Hi, Xuneng
> > >
> > > > > Is it worth/possible in recursive calls of ginScanToDelete() to free
> > > > > allocated myStackItem->child after processing all children of the
> > > > > current level, when they are not needed anymore?
> > > > > Previously to this patch, palloc-ed "me" variable also was't freed at
> > > > > recursion levels.
> > > >
> > > > Freeing/reallocating it per subtree would add churn and make the
> > > > lifetime rules harder to reason about without meaningful memory
> > > > savings (the number of nodes is bounded by tree depth, not number of
> > > > pages). We currently free the chain once after ginScanToDelete()
> > > > returns in ginVacuumPostingTree(), which matches the natural lifetime
> > > > boundary
> > > I proposed not freeing child when child iteration is complete. They
> > > indeed can be reused. I proposed cleaning children when "my" iteration
> > > is complete. At that time all the children iterations are completed
> > > and not needed when we return level up.
> > This is not clear for me.  We need stack items to keep track of left
> > pages until we scan the whole posting tree.  After scanning the whole
> > posting tree we can free stack items as we do now.
>
> You are right, that we can free all posting tree stack items after the
> whole tree, as we do now. But I think we can also do it earlier. It
> looks like all "children" items are needed and could be reused only
> until iteration on "my" level ends. When function returns up the
> recursion "my" level becomes "child" for a caller, and previous
> "child" is not used anymore.

No matter how many levels we can go up, we can still descend and need
the leftBuffer stored at any stack level.

------
Regards,
Alexander Korotkov
Supabase