Re: Odd code around ginScanToDelete - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Odd code around ginScanToDelete
Date
Msg-id CAPpHfdvwdoMNZh-pgg9NiYT_rexcsze5OfyB8cZHS6XFSNMsnw@mail.gmail.com
Whole thread Raw
In response to Re: Odd code around ginScanToDelete  (Pavel Borisov <pashkin.elfe@gmail.com>)
Responses Re: Odd code around ginScanToDelete
List pgsql-hackers
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.

------
Regards,
Alexander Korotkov
Supabase



pgsql-hackers by date:

Previous
From: "Matheus Alcantara"
Date:
Subject: Re: [PATCH] llvmjit: always add the simplifycfg pass
Next
From: Pavel Borisov
Date:
Subject: Re: Odd code around ginScanToDelete