Re: Locking B-tree leafs immediately in exclusive mode

On Mon, Jun 11, 2018 at 1:06 PM Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 5 June 2018 at 14:45, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> > Currently _bt_search() always locks leaf buffer in shared mode (aka BT_READ),
> > while caller can relock it later. However, I don't see what prevents
> > _bt_search()
> > from locking leaf immediately in exclusive mode (aka BT_WRITE) when required.
> > When traversing downlink from non-leaf page of level 1 (lowest level of non-leaf
> > pages just prior to leaf pages), we know that next page is going to be leaf. In
> > this case, we can immediately lock next page in exclusive mode if required.
> > For sure, it might happen that we didn't manage to exclusively lock leaf in this
> > way when _bt_getroot() points us to leaf page. But this case could be handled
> > in _bt_search() by relock. Please, find implementation of this approach in the
> > attached patch.
>
> It's a good idea. How does it perform with many duplicate entries?

Our B-tree is currently maintaining duplicates unordered. So, during insertion
we can traverse rightlinks in order to find page, which would fit new
index tuple.
However, in this case we're traversing pages in exclusive lock mode, and
that happens already after re-lock. _bt_search() doesn't do anything with that.
So, I assume there shouldn't be any degradation in the case of many
duplicate entries.

But this case definitely worth testing, and I'm planning to do it.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company