Re: Sort support for macaddr8
От | Melanie Plageman |
---|---|
Тема | Re: Sort support for macaddr8 |
Дата | |
Msg-id | CAAKRu_bYZ44gGjW5_d0O0yDRpkoPX4gjagqSW-s693CRfzm5dg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Sort support for macaddr8 (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Sort support for macaddr8
Re: Sort support for macaddr8 |
Список | pgsql-hackers |
On Tue, Jun 4, 2019 at 3:50 PM Peter Geoghegan <pg@bowt.ie> wrote:
On Tue, Jun 4, 2019 at 3:23 PM Andres Freund <andres@anarazel.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 tinkered a bit last night and got in/out mostly working (I think).
I'm not sure about macaddr, TID, and user-defined types.
--
Melanie Plageman
В списке pgsql-hackers по дате отправления: