Hi, On 2019-06-04 17:37:35 -0400, Alvaro Herrera wrote: > On 2019-Jun-03, Peter Geoghegan wrote: > > As you know, it's a bit weird that we're proposing adding sort support > > with abbreviated keys for a type that is 8 bytes, since you'd expect > > it to also be pass-by-value on most platforms, which largely defeats > > the purpose of having abbreviated keys (though sort support could > > still make sense, for the same reason it makes sense to have it for > > int8). However, macaddr8 isn't actually pass-by-value, and it seems > > too late to do anything about that now, so abbreviated keys actually > > make sense. > > I'm not sure I understand why you say it's too late to change now. > Surely the on-disk representation doesn't actually change, so it is not > impossible to change? And you make it sound like doing that change is > worthwhile, performance-wise.
Yea, I don't immediately see a problem with doing that on a major version boundary. Obviously that'd only be possible for sizeof(Datum) == 8 == sizeof(macaddr8) platforms, but that's the vast majority these days. And generally, I think it's just about *always* worth to go for a pass-by-value for the cases where that doesn't imply space wastage. I think it might be worthwhile to optimize things so that all typlen > 0 && typlen <= sizeof(Datum) are allowed for byval datums. SELECT typname, typlen FROM pg_type WHERE typlen > 0 AND typlen <= 8 AND NOT typbyval; ┌──────────┬────────┐ │ typname │ typlen │ ├──────────┼────────┤ │ tid │ 6 │ │ macaddr │ 6 │ │ macaddr8 │ 8 │ └──────────┴────────┘ (3 rows) Seems like adding byval support for sizes outside of 1/2/4/8 bytes would be worthwhile for tid alone. Not sure whether there's extensions with signifcant use that have fixed-width types <= 8 bytes. Greetings, Andres Freund
