On Fri, Mar 8, 2019 at 10:48 AM Peter Geoghegan <p...@bowt.ie> wrote: > > Question: Wouldn't it be more straightforward to use "1 +inf" as page > > 1's high key? I.e treat any missing columns as positive infinity. > > That might also work, but it wouldn't be more straightforward on > balance. This is because:
I thought of another reason: * The 'Add high key "continuescan" optimization' is effective because the high key of a leaf page tends to look relatively dissimilar to other items on the page. The optimization would almost never help if the high key was derived from the lastleft item at the time of a split -- that's no more informative than the lastleft item itself. As things stand with the patch, a high key usually has a value for its last untruncated attribute that can only appear on the page to the right, and never the current page. We'd quite like to be able to conclude that the page to the right can't be interesting there and then, without needing to visit it. Making new leaf high keys "as close as possible to items on the right, without actually touching them" makes the optimization quite likely to work out with the TPC-C indexes, when we search for orderline items for an order that is rightmost of a leaf page in the orderlines primary key. And another reason: * This makes it likely that any new items that would go between the original lastleft and firstright items end up on the right page when they're inserted after the lastleft/firstright split. This is generally a good thing, because we've optimized WAL-logging for new pages that go on the right. (You pointed this out to me in Lisbon, in fact.) -- Peter Geoghegan