On Tue, Jun 4, 2019 at 2:55 PM Andres Freund <and...@anarazel.de> wrote: > 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.
It would be faster to do it that way, I think. You would need a more complicated comparator than a classic abbreviated comparator (i.e. a 3-way unsigned int comparator) that way, but it would very probably be faster on balance. I'm glad to hear that it isn't *obviously* a problem from a compatibility perspective -- I really wasn't sure about that, since retrofitting a type to be pass-by-value like this is something that may never have been attempted before now (at least not since we started to care about pg_upgrade). > 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) This is half the reason why I ended up implementing itemptr_encode() to accelerate the TID sort used by CREATE INDEX CONCURRENTLY some years back -- TID is 6 bytes wide, which doesn't have the necessary macro support within postgres.h. There is no reason why that couldn't be added for the benefit of both TID and macaddr types, though it probably wouldn't be worth it. And, as long as we're not going to those lengths, there may be some value in keeping the macaddr8 code in line with macaddr code -- the two types are currently almost the same (the glaring difference is the lack of macaddr8 sort support). We'll need to draw the line somewhere, and that is likely to be a bit arbitrary. This was what I meant by "weird". -- Peter Geoghegan
