Re: range_agg

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: range_agg
Дата
Msg-id CAPpHfdu-CNAeZ_4bRr1JvsYcDMjFgEYEJ5Kmnt=QupZ4AcfH5Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: range_agg  (Alexander Korotkov <aekorotkov@gmail.com>)
Ответы Re: range_agg  (Alexander Korotkov <aekorotkov@gmail.com>)
Список pgsql-hackers
On Wed, Dec 16, 2020 at 7:14 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> On Wed, Dec 16, 2020 at 2:21 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > I decided to work on this patch myself.  The next revision is attached.
> >
> > The changes are as follows.
> >
> > 1. CREATE TYPE ... AS RANGE command now accepts new argument
> > multirange_type_name.  If multirange_type_name isn't specified, then
> > multirange type name is selected automatically.  pg_dump always
> > specifies multirange_type_name (if dumping at least pg14).  Thanks to
> > that dumps are always restorable.
> > 2. Multiranges now have a new binary format.  After the MultirangeType
> > struct, an array of offsets comes, then an array of flags and finally
> > bounds themselves.  Offsets points to the bounds of particular range
> > within multirange.  Thanks to that particular range could be accessed
> > by number without deserialization of the whole multirange.  Offsets
> > are stored in compression-friendly format similar to jsonb (actually
> > only every 4th of those "offsets" is really offsets, others are
> > lengths).
> > 3. Most of simple functions working with multirages now don't
> > deserialize the whole multirange.  Instead they fetch bounds of
> > particular ranges, and that doesn't even require any additional memory
> > allocation.
> > 4. I've removed ExpandedObject support from the patch.  I don't see
> > much point in it assuming all the functions are returning serialized
> > multirage anyway.  We can add ExpandedObject support in future if
> > needed.
> > 5. multirange_contains_element(), multirange_contains_range(),
> > multirange_overlaps_range() now use binary search.  Thanks to binary
> > format, which doesn't require full deserialization, these functions
> > now work with O(log N) complexity.
> >
> > Comments and documentation still need revision according to these
> > changes.  I'm going to continue with this.
>
> The next 27th revision is attached.  It contains minor documentation
> and code changes, in particular it should address
> commitfest.cputube.org complaints.

The next 28th revision is attached.  It comes with minor code
improvements, comments and commit message.

Also, given now we have a manual multirange type naming mechanism,
I've removed logic for prepending automatically generated names with
underscores to evade collision.  Instead, user is advised to name
multirange manually (as discussed in [1]).

I think this patch is very close to committable.  I'm going to spend
some more time further polishing it and commit (if I don't find a
major issue or face objections).

Links
1. https://www.postgresql.org/message-id/CALNJ-vSUpQ_Y%3DjXvTxt1VYFztaBSsWVXeF1y6gTYQ4bOiWDLgQ%40mail.gmail.com

------
Regards,
Alexander Korotkov

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Proposed patch for key managment
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [PATCH] nbtree: Do not show debugmessage if deduplication is disabled