Subject: Re: [WiP] B-tree page merge during vacuum to reduce index bloat

From: Madhav Madhusoodanan <[email-masked]>
Date: Fri, 27 Feb 2026 15:24:37 +0530

On Fri, Feb 27, 2026 at 2:33 AM Madhav Madhusoodanan
<[email-masked]> wrote:
>
> On Tue, Aug 26, 2025 at 2:11 PM Kirk Wolak <[email-masked]> wrote:
> > I do have a question, one of the IDEAS we discussed was to ADD a new page that combined the 2 pages.
>
> Would the flow then be as follows? Please correct me if I'm wrong:
> Start: Parent page P, with adjacent child pages A -> B -> C -> D.
> Pages B and C are sparse enough and are about to be merged.
> 1: Acquire lock on pages B and C
> 2: Create a new page N, which copies the tuples in pages B and C
> 3: Acquire lock on parent page P, update the separator keys in P,
> release lock on P
> 4: Update pointers such that pages link like so: A -> N -> D
> 5: Release lock on pages B and C
>
> Regards,
>
> Madhav

On a related note, I noticed the same topic on the 2026 projects list
in the Google Summer of Code page. It mentions that a prototype
extension (pg_btree_compact) has been developed. How do I access the
same?

Thanks in advance!

Madhav

---

From: Andrey Borodin <[email-masked]>
Date: Fri, 27 Feb 2026 15:58:21 +0500

> On 27 Feb 2026, at 14:54, Madhav Madhusoodanan <[email-masked]> wrote:
> 
> 

Hi Madhav!

It's available here [0], it's only a prototype.
But the approach with AccessExclusiveLock is not practically useful.
Just REINDEX INDEX CONCURRENTLY will do better in most cases.

We have to develop locking and pining protocols that:
1. Allow both Forward and Backward scans
2. Have indistinguishable locking and pining effect on index
Perhaps, I agree with Pavlo that it seems overly rigorous for GSoC.
It's more like math research than code typing.

Thanks for your interest!

Best regards, Andrey Borodin.

[0] https://github.com/x4m/postgres_g/commit/a5eea2d