On Wed, Mar 6, 2019 at 10:54 PM Peter Geoghegan <p...@bowt.ie> wrote: > It will also have to store heapkeyspace, of course. And minusinfkey. > BTW, I would like to hear what you think of the idea of minusinfkey > (and the !minusinfkey optimization) specifically.
> I'm not sure that that's an improvement. Moving right should be very > rare with my patch. gcov shows that we never move right here anymore > with the regression tests, or within _bt_check_unique() -- not once. > For a second, I thought that you forgot to invalidate the bounds_valid > flag, because you didn't pass it directly, by value to > _bt_useduplicatepage(). BTW, the !minusinfkey optimization is why we literally never move right within _bt_findinsertloc() while the regression tests run. We always land on the correct leaf page to begin with. (It works with unique index insertions, where scantid is NULL when we descend the tree.) In general, there are two good reasons for us to move right: * There was a concurrent page split (or page deletion), and we just missed the downlink in the parent, and need to recover. * We omit some columns from our scan key (at least scantid), and there are perhaps dozens of matches -- this is not relevant to _bt_doinsert() code. The single value strategy used by nbtsplitloc.c does a good job of making it unlikely that _bt_check_unique()-wise duplicates will cross leaf pages, so there will almost always be one leaf page to visit. And, the !minusinfkey optimization ensures that the only reason we'll move right is because of a concurrent page split, within _bt_moveright(). The buffer lock coupling move to the right that _bt_findinsertloc() does should be considered an edge case with all of these measures, at least with v4 indexes. -- Peter Geoghegan
