On Sun, Dec 27, 2020 at 9:07 PM David Fetter <david@fetter.org> wrote:
> On Sun, Dec 27, 2020 at 09:53:13AM -0800, Zhihong Yu wrote:
> > This is not an ideal way to index multirages, but something we can
> > easily have.
>
> What sort of indexing improvements do you have in mind?
Approximation of multirange as a range can cause false positives.
It's good if gaps are small, but what if they aren't.
Ideally, we should split multirange to the ranges and index them
separately. So, we would need a GIN-like index. The problem is that
the GIN entry tree is a B-tree, which is not very useful for searching
for ranges. If we could replace the GIN entry tree with GiST or
SP-GiST, that should be good. We could index multirage parts
separately and big gaps wouldn't be a problem. Similar work was
already prototyped (it was prototyped under the name "vodka", but I'm
not a big fan of this name). FWIW, such a new access method would
need a lot of work to bring it to commit. I don't think it would be
reasonable, before multiranges get popular.
Regarding the GiST opclass, it seems the best we can do in GiST.
------
Regards,
Alexander Korotkov
