Re: range_agg

On Wed, Dec 16, 2020 at 7:14 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>
> On Wed, Dec 16, 2020 at 2:21 AM Alexander Korotkov <aekorotkov(at)gmail(dot)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