Re: Locking B-tree leafs immediately in exclusive mode

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Locking B-tree leafs immediately in exclusive mode
Date: 2018-07-09 22:49:10
Message-ID: CAH2-WzmY3JMztGrL6NmB4Us9KnhnB+1k6P649z_ahT8+95fFTA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 9, 2018 at 3:23 PM, Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> I'm sorry, but I didn't understand this guess. I agree that moving
> right within _bt_findinsertloc() might be worse than moving right
> within _bt_moveright(). But why should it happen more often, if both
> with and without patch that happens only after _bt_moveright() in
> exclusive mode (with patch _bt_search() calls _bt_moveright() in
> exclusive mode)?

_bt_moveright() doesn't serialize access, because it doesn't couple
buffer locks. I think that it's possible that it's slower for that
reason -- not because it moves right more often.

"The Convoy Phenomenon" research report may be worth a read sometime,
though it's very old. It's co-authored by Jim Gray. As they put it,
sometimes "a non-FIFO strategy" can be faster. In simple terms,
sometimes it can be faster to randomly grant a lock, since in practice
nobody gets starved out. I'm guessing (and it is very much a guess)
that it could be something like that, since the behavior of
_bt_findinsertloc() can be FIFO-like, whereas the behavior of
_bt_moveright() may not be.

Again, the actual queries would help a lot. It's just a guess.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-07-09 23:24:43 Re: [HACKERS] Clock with Adaptive Replacement
Previous Message Tom Lane 2018-07-09 22:24:28 Re: Failure assertion in GROUPS mode of window function in current HEAD