On Mon, Jun 11, 2018 at 1:06 PM Simon Riggs <si...@2ndquadrant.com> wrote: > On 5 June 2018 at 14:45, Alexander Korotkov <a.korot...@postgrespro.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
