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/access/nbtree.h#L63
