On Fri, Feb 27, 2026 at 5:37 PM Matthias van de Meent <[email protected]> wrote: > > That is one part of the picture (the merging part), but it's missing a > lot of details: > - How do concurrent workloads (index scans, backwards index scans, > index insertions) detect and recover from concurrent merges when they > step through pages? > - Do you have a theory or proof of correctness for the above? > - Can this scheme be implemented without adding significant overhead > to current workloads that don't benefit significantly from the new > feature? > > One example for a problem with the given flow: where (and how) do you > update the sibling pointers in pages A (to N from B) and D (to N from > C)? > You haven't explicitly locked pages A and D by the time you get to > step 4, even though locking pages is critical to guarantee correct and > safe operations. Simply locking them in step 4 isn't sufficient, as > another process may have locked page A in preparation for a split, > which would then be waiting to get a lock on page B. If you've already > locked page B before locking page A, you'll have a deadlock. > > Additionally, how does this work when you find out in step 3 that your > pages B and C each are linked to from a different parent page? You'd > have to update both parent pages, but that would also require locking > more than just the one parent page per level that currently gets > locked during page deletion.
Ohh I see, I haven't included the dynamics of such flows too. I might have to think this through. Thank you for pointing it out! Just to understand what we can control (and to help internalize the constraints so that I can think through a strategy): to handle transient merge states, are we intending to update core? Or is the bloat reduction functionality intended to be abstracted into an extension? I'm coming up with ways that might potentially update index amcheck and the like. Thanks in advance! Madhav
