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
