MIME-Version: 1.0
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>
In-Reply-To: 
 <CALT9ZEFnE_aJ=nr5nMSxLYsNCfnKVOPFbiMZo5T_VoMb-sjO6Q@mail.gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Thu, 12 Mar 2026 00:37:31 +0200
Message-ID: 
 <CAPpHfdtfJ66rfZXO__gyDCyKBbusqXA_JtebXQNZuE_O-smRVw@mail.gmail.com>
Subject: Re: Odd code around ginScanToDelete
To: Pavel Borisov <pashkin.elfe@gmail.com>
Cc: Xuneng Zhou <xunengzhou@gmail.com>, Andres Freund <andres@anarazel.de>,
	pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPpHfdtfJ66rfZXO__gyDCyKBbusqXA_JtebXQNZuE_O-smRVw%40mail.gmail.com>
Precedence: bulk

On Thu, Mar 12, 2026 at 12:35=E2=80=AFAM Pavel Borisov <pashkin.elfe@gmail.=
com> wrote:
>
> On Thu, 12 Mar 2026 at 02:22, Alexander Korotkov <aekorotkov@gmail.com> w=
rote:
> >
> > On Tue, Mar 10, 2026 at 11:29=E2=80=AFAM Pavel Borisov <pashkin.elfe@gm=
ail.com> wrote:
> > > Hi, Xuneng
> > >
> > > > > Is it worth/possible in recursive calls of ginScanToDelete() to f=
ree
> > > > > 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 free=
d 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 o=
f
> > > > pages). We currently free the chain once after ginScanToDelete()
> > > > returns in ginVacuumPostingTree(), which matches the natural lifeti=
me
> > > > boundary
> > > I proposed not freeing child when child iteration is complete. They
> > > indeed can be reused. I proposed cleaning children when "my" iteratio=
n
> > > 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