Re: Locking B-tree leafs immediately in exclusive mode
От | Peter Geoghegan |
---|---|
Тема | Re: Locking B-tree leafs immediately in exclusive mode |
Дата | |
Msg-id | CAH2-WzmY3JMztGrL6NmB4Us9KnhnB+1k6P649z_ahT8+95fFTA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Locking B-tree leafs immediately in exclusive mode (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Список | pgsql-hackers |
On Mon, Jul 9, 2018 at 3:23 PM, Alexander Korotkov <a.korotkov@postgrespro.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
В списке pgsql-hackers по дате отправления: