Re: [GSoC 2026] - B-tree Index Bloat Reduction - Approach & Questions

On Fri, Jun 26, 2026 at 10:54 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Jun 23, 2026 at 4:46 PM Kirk Wolak <wolakk(at)gmail(dot)com> wrote:
> >> (Today's lesson for her, is how to defend your position, while being
> prepared for the public beat down (lol) where you might be wrong. Be wrong
> out loud! You learn faster!)
> >
> ... The fact that they care
> enough to respond is a good sign, not a bad one.
>
> ...
>
> I suspect everyone here would love to see a solution to this problem,
> but I would personally be beyond impressed if someone managed to come
> up with even a working prototype for this in one summer. Even a
> respectable amount of progress on figuring out an algorithm would be a
> good result, IMHO.
>

Okay, first, thanks for the thoughtful response(s) from everyone!

As for changing the GSoC project. Nah... We don't mind hard. Our
fallback position always was that the project
will be successful if it changed the discussion and made it "SEEM"
possible, and left behind the "currently unstated requirements"

Also, we have almost 7 full weeks to the mid-terms, and at this point, we
have a rough prototype, and will have the Vacuum Cleanup
process before the mid-term (it's a 22 week long project, ending in
November). We are crossing our Ts in this process, but will provide some
PoC code in order to garner "Feedback" once the vacuum and the complete
life cycle is handled.

To be clear. Our goal is the 80/20 level implementation. Something that
is provably correct, has very little impact on normal scans, etc.
We only work on LEAF nodes... Because that's where the 80/20 lays for
now. Honestly, with all of our restrictions, it will take MANY passes to
remove all of the bloat we can. The upside of this approach was
ACCIDENTAL... That it probably fits better INSIDE of autovacuum! (Again,
beyond our current scope).

We have a lot of hurdles to clear. Many of them, we probably do not even
know yet. But the feedback so far has helped us to rethink, rewrite and
improve the logic (no ghost records on the L page, no extra data required
on the BTP_MERGED pages).

Also, we have an assumption that we will not delete BTP_MERGED[_AWAY] pages
until the "Family" of leaf nodes have been reset back to normal. TBH, the
visibility horizon on a future delete must be after the visibility horizon
on the cleanup process. (Currently, the existence of a half_dead page in
the middle would break assumptions). But since it is vacuums job to reset
these to normal pages, as it does so, it can also start marking them
half_dead and ultimately remove them. (We are still studying Vacuum, so if
I sound like I am speaking tongues to those who KNOW better... Forgive
me. It's a high-level statement).

Suffice it to say. We are quite happy with the progress so far.

Kirk