28.09.2018 23:08, Peter Geoghegan wrote:
On Fri, Sep 28, 2018 at 7:50 AM Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
I think it might help this patch move along if it were split up a bit,
for example 1) suffix truncation, 2) tid stuff, 3) new split strategies.
That way, it would also be easier to test out each piece separately.
For example, how much space does suffix truncation save in what
scenario, are there any performance regressions, etc.
I'll do my best. I don't think I can sensibly split out suffix
truncation from the TID stuff -- those seem truly inseparable, since
my mental model for suffix truncation breaks without fully unique
keys. I can break out all the cleverness around choosing a split point
into its own patch, though -- _bt_findsplitloc() has only been changed
to give weight to several factors that become important. It's the
"brain" of the optimization, where 90% of the complexity actually
lives.
Removing the _bt_findsplitloc() changes will make the performance of
the other stuff pretty poor, and in particular will totally remove the
benefit for cases that "become tired" on the master branch. That could
be slightly interesting, I suppose.
I am reviewing this patch too. And join to Peter Eisentraut opinion
about splitting the patch into a hierarchy of two or three patches:
"functional" - tid stuff and "optimizational" - suffix truncation &
splitting. My reasons are simplification of code review, investigation
and benchmarking.
Now benchmarking is not clear. Possible performance degradation from TID
ordering interfere with positive effects from the optimizations in
non-trivial way.
--
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company
