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
