]> granicus.if.org Git - postgresql/commit
Fix pathological nbtree split point choice issue.
authorPeter Geoghegan <pg@bowt.ie>
Mon, 15 Jul 2019 20:19:13 +0000 (13:19 -0700)
committerPeter Geoghegan <pg@bowt.ie>
Mon, 15 Jul 2019 20:19:13 +0000 (13:19 -0700)
commite3899ffd8beafdaaa037b503163a9f572e9fc729
treeb46b5af149e6ea9a7dabd99c3d06f2c8d3f1f2c5
parent1cff1b95ab6ddae32faa3efe0d95a820dbfdc164
Fix pathological nbtree split point choice issue.

Specific ever-decreasing insertion patterns could cause successive
unbalanced nbtree page splits.  Problem cases involve a large group of
duplicates to the left, and ever-decreasing insertions to the right.

To fix, detect the situation by considering the newitem offset before
performing a split using nbtsplitloc.c's "many duplicates" strategy.  If
the new item was inserted just to the right of our provisional "many
duplicates" split point, infer ever-decreasing insertions and fall back
on a 50:50 (space delta optimal) split.  This seems to barely affect
cases that already had acceptable space utilization.

An alternative fix also seems possible.  Instead of changing
nbtsplitloc.c split choice logic, we could instead teach _bt_truncate()
to generate a new value for new high keys by interpolating from the
lastleft and firstright key values.  That would certainly be a more
elegant fix, but it isn't suitable for backpatching.

Discussion: https://postgr.es/m/CAH2-WznCNvhZpxa__GqAa1fgQ9uYdVc=_apArkW2nc-K3O7_NA@mail.gmail.com
Backpatch: 12-, where the nbtree page split enhancements were introduced.
src/backend/access/nbtree/nbtsplitloc.c