Thread: Split interval (used by nbtree suffix truncation) and posting list tuples
Split interval (used by nbtree suffix truncation) and posting list tuples
From
Peter Geoghegan
Date:
We choose a split point in nbtsplitloc.c primarily based on evenly dividing space among left and right halves of the split, while giving secondary consideration to suffix truncation (there is other logic that kicks in when there are many duplicates, which isn't related to what I want to talk about). See my commit fab25024 from Postgres 12 for background information. The larger the split interval, the more unbalanced page splits are allowed to be, which is a cost that we may be willing to pay to truncate more suffix attributes in the new high key. Split interval represents a trade-off between two competing considerations (a potential cost versus a potential benefit). Unfortunately, commit fab25024 defined "split interval" based on logic that makes the assumption that tuples on the same page are more or less of a uniform size. That assumption was questionable when suffix truncation went in, but now that deduplication exists the assumption seems quite risky. I am concerned that suffix truncation will be far more aggressive than appropriate when the delta-optimal split point is near large posting list tuples, that are size outliers on the page. The logic in nbtsplitloc.c might accept a much more unbalanced page split than is truly reasonable because the average width of tuples on the page isn't so large, even though the tuples around where we want to split the page are very large. Fortunately it's pretty easy to nail this down. We can determine the default strategy split interval based on the cost that we actually care about (not a fuzzy proxy of that cost): a leftfree and rightfree space tolerance from the space optimal candidate split point, expressed in bytes (actually, expressed as a proportion of the total space that is used for data items on the page, which is converted into bytes to form a tolerance). That's the way it's done in the attached patch. I plan to commit this patch next week, barring any objections. -- Peter Geoghegan