Re: Why B-Tree suffix truncation matters

Hi, Peter!

> 4 июля 2018 г., в 20:43, Peter Geoghegan <pg@bowt.ie> написал(а):
>
> I've been working on B-Tree suffix truncation

Thank you for this detailed explanation. I must admit I've been seriously confusing prefix truncation and suffix
truncationbefore this post. 

Some years ago I've observed viable performance improvement (around 8% in inserts and 5% in selects) of covering
indexesin a series of experiments [0]. I believe same improvement may be achieved by suffix truncation in case of
complexcomposite indexes. 

> Unlike techniques like prefix compression, suffix
> truncation leaves us with little to lose, so we don't need buy-in from
> the user. No new GUCs required.

Indeed, but prefix truncation can reduce whole index size dramatically, not by a matter of few percents. If we have
foreignkey from table 1 with 1M tuples to table 2 with 1K rows, index size can be reduced by the order of magnitude.
Andthis optimization seems very straightforward: trim tuple's prefix, if it matches hikey's prefix (or some other's in
caseof leaf page). 


> The downside of trying to truncate seems like it could be made to be
> close to zero.
I see code complexity as somewhat a downside. B-tree is kind of a rocket science. Chances are you have some kind of
roadmapof B-tree things to implement in nearest years? 

Best regards, Andrey Borodin.

[0] https://www.postgresql.org/message-id/20160814171131.21390.75752.pgcf%40coridan.postgresql.org