public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexander Korotkov <[email protected]>
To: Pavel Borisov <[email protected]>
Cc: Xuneng Zhou <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: [email protected]
Subject: Re: Odd code around ginScanToDelete
Date: Thu, 12 Mar 2026 00:37:31 +0200
Message-ID: <CAPpHfdtfJ66rfZXO__gyDCyKBbusqXA_JtebXQNZuE_O-smRVw@mail.gmail.com> (raw)
In-Reply-To: <CALT9ZEFnE_aJ=nr5nMSxLYsNCfnKVOPFbiMZo5T_VoMb-sjO6Q@mail.gmail.com>
References: <utrlxij43fbguzw4kldte2spc4btoldizutcqyrfakqnbrp3ir@ph3sphpj4asz>
<CAPpHfdt5BHkpvFnwg_RiMrCdD8W5FhOoahqY2Td-y3kb45UpZw@mail.gmail.com>
<CAPpHfduJQPTrXpJr=-mHtsJH8+1v_X389K6trajPzhnA37C9nA@mail.gmail.com>
<CALT9ZEGioDdvkx1rmjVzOW5nyxsxjX16FVifYY4b7MVFuc_80g@mail.gmail.com>
<CABPTF7X2HXXiUk1+Vd_pzPhiYOHw0y=OnDXW87G7hfPL0577hw@mail.gmail.com>
<CALT9ZEGsc3oSqtaHtevz5=SZaooW6hPP8ZwNEZCSEw2kePaHvQ@mail.gmail.com>
<CAPpHfdvwdoMNZh-pgg9NiYT_rexcsze5OfyB8cZHS6XFSNMsnw@mail.gmail.com>
<CALT9ZEFnE_aJ=nr5nMSxLYsNCfnKVOPFbiMZo5T_VoMb-sjO6Q@mail.gmail.com>
On Thu, Mar 12, 2026 at 12:35 AM Pavel Borisov <[email protected]> wrote:
>
> On Thu, 12 Mar 2026 at 02:22, Alexander Korotkov <[email protected]> wrote:
> >
> > On Tue, Mar 10, 2026 at 11:29 AM Pavel Borisov <[email protected]> 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
view thread (13+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Odd code around ginScanToDelete
In-Reply-To: <CAPpHfdtfJ66rfZXO__gyDCyKBbusqXA_JtebXQNZuE_O-smRVw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox