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>
 <CAKw2Pb3XJXMPv6zPVwrnTJDZkD+SpUkK61B2hjj+D+KGPWahHA@mail.gmail.com>
In-Reply-To: 
 <CAKw2Pb3XJXMPv6zPVwrnTJDZkD+SpUkK61B2hjj+D+KGPWahHA@mail.gmail.com>
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
Date: Tue, 10 Mar 2026 12:53:10 +0100
Message-ID: 
 <CAEze2WjL6sXRrT6sSFzaCZUma7GJyOkMkGKXOHT1GuojUScpcQ@mail.gmail.com>
Subject: Re: [WiP] B-tree page merge during vacuum to reduce index bloat
To: Madhav Madhusoodanan <madhavmadhusoodanan@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/CAEze2WjL6sXRrT6sSFzaCZUma7GJyOkMkGKXOHT1GuojUScpcQ%40mail.gmail.com>
Precedence: bulk

On Tue, 10 Mar 2026 at 06:09, Madhav Madhusoodanan
<madhavmadhusoodanan@gmail.com> wrote:
>
> 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 a=
s 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?

They're exclusively for btree code's use; extensions (*) must not add
to (or change the meaning of) those bits, lest they create a forward
incompatibility with core PostgreSQL btree code in newer major
versions; it would cause corrupted binary upgraded databases.
But patches against core btree code can use those bits, because
forward compatibility is less of an issue there - we don't really
support binary upgrades manually patched systems, especially if they
have incompatible on-disk data.

(*): I'm skeptical about whether you could make btree scans handle
concurrently merged pages, when that merging is implemented as
extension and the btree code doesn't know about merges.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)