On Wed, Dec 6, 2023 at 11:14 AM Matthias van de Meent <boekewurm+postg...@gmail.com> wrote: > I was thinking more along the lines of page splits+deletions while > we're doing _bt_stepright(), but forgot to consider that we first lock > the right sibling, and only then release the left sibling for splits, > so we should be fine here.
In general the simplest (and possibly most convincing) arguments for the correctness of optimizations like the ones that Alexander added rely on seeing that the only way that the optimization can be wrong is if some more fundamental and long established thing was also wrong. We could try to prove that the new optimization is correct (or wrong), but it is often more helpful to "prove" that some much more fundamental thing is correct instead, if that provides us with a useful corollary about the new thing also being correct. Take the _bt_readpage precheck optimization, for example. Rather than thinking about the key space and transitive rules, it might be more helpful to focus on what must have been true in earlier Postgres versions, and what we can expect to still hold now. The only way that that optimization could be wrong is if the same old _bt_checkkeys logic that decides when to terminate the scan (by setting continuescan=false) always had some propensity to "change its mind" about ending the scan, at least when it somehow got the opportunity to see tuples after the first tuple that it indicated should end the scan. That's not quite bulletproof, of course (it's not like older Postgres versions actually provided _bt_checkkeys with opportunities to "change its mind" in this sense), but it's a useful starting point IME. It helps to build intuition. -- Peter Geoghegan
