public inbox for [email protected]
help / color / mirror / Atom feedFrom: Matthias van de Meent <[email protected]>
To: Madhav Madhusoodanan <[email protected]>
Cc: Kirk Wolak <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Nikolay Samokhvalov <[email protected]>
Subject: Re: [WiP] B-tree page merge during vacuum to reduce index bloat
Date: Tue, 10 Mar 2026 12:53:10 +0100
Message-ID: <CAEze2WjL6sXRrT6sSFzaCZUma7GJyOkMkGKXOHT1GuojUScpcQ@mail.gmail.com> (raw)
In-Reply-To: <CAKw2Pb3XJXMPv6zPVwrnTJDZkD+SpUkK61B2hjj+D+KGPWahHA@mail.gmail.com>
References: <[email protected]>
<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>
On Tue, 10 Mar 2026 at 06:09, Madhav Madhusoodanan
<[email protected]> wrote:
>
> On Fri, Mar 6, 2026 at 2:15 AM Madhav Madhusoodanan
> <[email protected]> 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?
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)
view thread (14+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [WiP] B-tree page merge during vacuum to reduce index bloat
In-Reply-To: <CAEze2WjL6sXRrT6sSFzaCZUma7GJyOkMkGKXOHT1GuojUScpcQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox