Re: Why B-Tree suffix truncation matters

Hi, Peter!

> 4 июля 2018 г., в 20:43, Peter Geoghegan <pg(at)bowt(dot)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 truncation before this post.

Some years ago I've observed viable performance improvement (around 8% in inserts and 5% in selects) of covering indexes in a series of experiments [0]. I believe same improvement may be achieved by suffix truncation in case of complex composite 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 foreign key from table 1 with 1M tuples to table 2 with 1K rows, index size can be reduced by the order of magnitude. And this optimization seems very straightforward: trim tuple's prefix, if it matches hikey's prefix (or some other's in case of 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 roadmap of 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