On Tue, Feb 11, 2020 at 1:40 PM Alvaro Herrera <alvherre@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
