Re: Sort support for macaddr8

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