On Sun, Dec 27, 2020 at 9:07 PM David Fetter <da...@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