28.09.2018 23:08, Peter Geoghegan wrote:
> On Fri, Sep 28, 2018 at 7:50 AM Peter Eisentraut
> <peter.eisentraut@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