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

From Pavel Borisov
Subject Re: Odd code around ginScanToDelete
Date
Msg-id CALT9ZEGsc3oSqtaHtevz5=SZaooW6hPP8ZwNEZCSEw2kePaHvQ@mail.gmail.com
Whole thread
In response to Re: Odd code around ginScanToDelete  (Xuneng Zhou <xunengzhou@gmail.com>)
Responses Re: Odd code around ginScanToDelete
List pgsql-hackers
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.

Regards,
Pavel Borisov
Supabase



pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: Add missing CHECK_FOR_INTERRUPTS calls in dblink module
Next
From: Kirill Reshke
Date:
Subject: Re: domain for WITHOUT OVERLAPS