From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sort support for macaddr8 |
Date: | 2019-06-05 18:55:35 |
Message-ID: | 20190605185535.uigqarmdprlsp7ed@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-06-05 09:18:34 -0700, Melanie Plageman wrote:
> On Tue, Jun 4, 2019 at 3:50 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> > On Tue, Jun 4, 2019 at 3:23 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > > 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.
> >
> > On second thought, maybe there is something to be said for being
> > exhaustive here.
> >
> > It seems like there is a preference for making macaddr8 pass-by-value
> > instead of adding abbreviated keys support to macaddr8, and possibly
> > doing the same with the original macaddr type.
> >
> > Do you think that you'll be able to work on the project with this
> > expanded scope, Melanie?
> >
> >
> I can take on making macaddr8 pass-by-value
> I tinkered a bit last night and got in/out mostly working (I think).
> I'm not sure about macaddr, TID, and user-defined types.
I'd much rather see this tackled in a general way than fiddling with
individual datatypes. I think we should:
1) make fetch_att(), store_att_byval() etc support datums of any length
between 1 and <= sizeof(Datum). Probably also convert them to inline
functions. There's a few more functions to be adjusted, but not many,
I think.
2) Remove ability to pass PASSEDBYVALUE to CREATE TYPE, but instead
compute whether attyval is possible, solely based on INTERNALLENGTH
(when INTERNALLENGTH > 0 obviously).
3) Fix the fallout, by fixing a few of the Datum<->type conversion
functions affected by this change. That'll require a bit of work, but
not too much. We should write those conversion routines in a way
that'll keep them working for the scenarios where the type is
actually passable by value, and not (required for > 4 byte datums).
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-06-05 19:14:42 | Re: Sort support for macaddr8 |
Previous Message | Alvaro Herrera | 2019-06-05 17:41:46 | Re: Sort support for macaddr8 |