Hi,
On 2019-06-04 15:10:07 -0700, Peter Geoghegan wrote:
> On Tue, Jun 4, 2019 at 2:55 PM Andres Freund <andres@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'd be surprised if it weren't.
> 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).
Obviously we have to test it, but I don't really see any compat
problems. Both have the same size on disk, after all. We couldn't make
such a change in a minor version, as DatumGetMacaddr*,
DatumGetItemPointer obviously need to change, but it ought to otherwise
be transparent. It would, I think, be different if we still supported
v0 calling conventions, but we don't...
> 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.
I think we should definitely do that. It seems not unlikely that other
people want to write new fixed width types, and we shouldn't have them
deal with all this complexity unnecessarily.
Greetings,
Andres Freund