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
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 |