On Wed, Mar 6, 2019 at 11:41 PM Heikki Linnakangas <hlinn...@iki.fi> wrote: > > BTW, I would like to hear what you think of the idea of minusinfkey > > (and the !minusinfkey optimization) specifically. > > I don't understand it :-(. I guess that's valuable feedback on its own. > I'll spend more time reading the code around that, but meanwhile, if you > can think of a simpler way to explain it in the comments, that'd be good.
Here is another way of explaining it: When I drew you that picture while we were in Lisbon, I mentioned to you that the patch sometimes used a sentinel scantid value that was greater than minus infinity, but less than any real scantid. This could be used to force an otherwise-equal-to-pivot search to go left rather than uselessly going right. I explained this about 30 minutes in, when I was drawing you a picture. Well, that sentinel heap TID thing doesn't exist any more, because it was replaced by the !minusinfkey optimization, which is a *generalization* of the same idea, which extends it to all columns (not just the heap TID column). That way, you never have to go to two pages just because you searched for a value that happened to be at the "right at the edge" of a leaf page. Page deletion wants to assume that truncated attributes from the high key of the page being deleted have actual negative infinity values -- negative infinity is a value, just like any other, albeit one that can only appear in pivot tuples. This is simulated by VACUUM using "minusinfkey = true". We go left in the parent, not right, and land on the correct leaf page. Technically we don't compare the negative infinity values in the pivot to the negative infinity values in the scankey, but we return 0 just as if we had, and found them equal. Similarly, v3 indexes specify "minusinfkey = true" in all cases, because they always want to go left -- just like in old Postgres versions. They don't have negative infinity values (matches can be on either side of the all-equal pivot, so they must go left). -- Peter Geoghegan
