MIME-Version: 1.0
References: <11A59C0C-A8C8-4642-8493-292D5DF8311D@yandex-team.ru>
 <CAEze2Wg2a8LQDRocVPa7Df2qXQLrTz-xSu1k3xP3x_6ABVo1Jw@mail.gmail.com>
 <CACLU5mRude0L5psEj5WS0DVDv=AHN0McfZBKV5eBoW0JqwwZDA@mail.gmail.com>
 <CAKw2Pb2wV=L4yeAqj27wJ1wptHt1mnBaQ5t4YuLLe+M5aU6ESg@mail.gmail.com>
 <CAEze2WhPwEAszAOV+3_Oc63V=8JcnsY_4FD3XRLzRi0q0nNdUA@mail.gmail.com>
 <CAKw2Pb19rE+sJPpCXhfk8T4K+snfa240_eDXs0dqpCsXoS6cgA@mail.gmail.com>
 <CAKw2Pb3=PrcznZuweLLyHt4gmRLyO9cffqRfTm27BFgruGWgWw@mail.gmail.com>
In-Reply-To: 
 <CAKw2Pb3=PrcznZuweLLyHt4gmRLyO9cffqRfTm27BFgruGWgWw@mail.gmail.com>
From: Madhav Madhusoodanan <madhavmadhusoodanan@gmail.com>
Date: Tue, 10 Mar 2026 10:39:07 +0530
Message-ID: 
 <CAKw2Pb3XJXMPv6zPVwrnTJDZkD+SpUkK61B2hjj+D+KGPWahHA@mail.gmail.com>
Subject: Re: [WiP] B-tree page merge during vacuum to reduce index bloat
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Kirk Wolak <wolakk@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
 Nikolay Samokhvalov <nik@postgres.ai>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAKw2Pb3XJXMPv6zPVwrnTJDZkD%2BSpUkK61B2hjj%2BD%2BKGPWahHA%40mail.gmail.com>
Precedence: bulk

On Fri, Mar 6, 2026 at 2:15=E2=80=AFAM Madhav Madhusoodanan
<madhavmadhusoodanan@gmail.com> wrote:
>
> Some parts of the merge flow that I am coming up with are as follows
> (assuming tuples from index page B are migrated rightwards into C):
>
> 1. Leaving B's tuples as it is even after merge, to remove the
> possible risk of scans "skipping over" tuples. Essentially, the tuples
> then would be "copied" into C.
> 2. Marking pages B and C with flags similar to INCOMPLETE_SPLIT (say,
> MERGE_SRC and MERGE_DEST respectively) before the actual merge
> process, then marking the pages with another flag upon completion
> (MERGE_COMPLETE) so that other processes can handle transient merge
> states.
> 3. For example, scans that reach page B post-merge (MERGE_SRC +
> MERGE_COMPLETE) would be made to skip to the page to its right.
> 4. Updating VACUUM to handle post-merge cleanup (to remove pages such as =
B).
>

I was going through the source code to understand whether the
aforementioned direction of changes would be reasonable.

I was observing `BTPageOpaqueData.btpo_flags` [0] which is a uint16,
but only 9 bits are used.

Would using a couple bits of the same for this purpose be reasonable?
Or are they being reserved for future functionality?

Thanks!

Madhav

[0] https://github.com/postgres/postgres/blob/03facc1211b0ff1550f41bcd4da09=
329080c30f9/src/include/access/nbtree.h#L63