Re: Randomize B-Tree page split location to avoid oscillating patterns

Hi,

On 2026-04-27 14:07:14 -0400, Peter Geoghegan wrote:
> On Mon, Apr 27, 2026 at 12:24 PM Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
> > The unfortunate part is that I couldn't get clear numbers for the performance
> > impact. Turns out the disk in my experimental setup is not good enough to get a
> > sufficient number of inserts to trigger the issue, and to get nice graphs I was
> > running everything either on a RAM disk or on an unlogged table -- in both
> > cases it's easy to observe oscillations of page splits, but their impact is not
> > large enough since only so much IO is happening.
> >
> > But anyway, any thoughts / commentaries on that?
>
> I wouldn't expect the patch to increase absolute throughput
> significantly, if at all. Its value comes from making the *rate* of
> splits over time more consistent, for a given fixed workload. You
> might notice a more interesting effect if you look at latency,
> particularly worst case latency.

Possibly somewhat orthogonal, but the worst case latency point reminded me of
something around this:

It seems like it's not great for contention avoidance / concurrency that right
now btree splits will often do IO - to write out a victim buffer and then to
extend the relation - while holding an exclusive lock on a page.

Couldn't we instead release the lock on the page, acquire an empty page,
reacquire the lock, recheck that the split is still needed and, if so, split
the page without needing to do IO while holding the lock?

Greetings,

Andres Freund