public inbox for [email protected]  

help / color / mirror / Atom feed
From: Madhav Madhusoodanan <[email protected]>
To: Matthias van de Meent <[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 10:39:07 +0530
Message-ID: <CAKw2Pb3XJXMPv6zPVwrnTJDZkD+SpUkK61B2hjj+D+KGPWahHA@mail.gmail.com> (raw)
In-Reply-To: <CAKw2Pb3=PrcznZuweLLyHt4gmRLyO9cffqRfTm27BFgruGWgWw@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>

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?

Thanks!

Madhav

[0] https://github.com/postgres/postgres/blob/03facc1211b0ff1550f41bcd4da09329080c30f9/src/include/acces...





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: <CAKw2Pb3XJXMPv6zPVwrnTJDZkD+SpUkK61B2hjj+D+KGPWahHA@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