Hi, Peter! > 4 июля 2018 г., в 20:43, Peter Geoghegan <p...@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 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
