Thank you for both your feedback. Yes, as indicated by Peter, we indeed use that technique in comparison in index, and now we will try passing comparator to the storage engine according to Alvaro's suggestion.
Best, Shichao On Tue, 11 Feb 2020 at 17:16, Peter Geoghegan <p...@bowt.ie> wrote: > On Tue, Feb 11, 2020 at 1:40 PM Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: > > I think adding that would be too much of a burden, both for the project > > itself as for third-party type definitions; I think we'd rather rely on > > calling the BTORDER_PROC btree support function for the type. > > An operator class would still need to provide a BTORDER_PROC. What I > describe would be an optional capability. This is something that I > have referred to as key normalization in the past: > > https://wiki.postgresql.org/wiki/Key_normalization > > I think that it would only make sense as an enabler of multiple > optimizations -- not just the memcmp()/strcmp() thing. A common > strcmp()'able binary string format can be used in many different ways. > Note that this has nothing to do with changing the representation used > by the vast majority of all tuples -- just the pivot tuples, which are > mostly located in internal pages. They only make up less than 1% of > all pages in almost all cases. > > I intend to prototype this technique within the next year. It's > possible that it isn't worth the trouble, but there is only one way to > find out. I might just work on the "abbreviated keys in internal > pages" thing, for example. Though you really need some kind of prefix > compression to make that effective. > > -- > Peter Geoghegan > -- Shichao Jin PhD Student at University of Waterloo, Canada e-mail: jsc0...@gmail.com homepage: http://sites.google.com/site/csshichaojin/
