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
|
Список | 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 по дате отправления: