Hello Paul, thanks for the thorough response to all these points.
Regarding the merge of multiranges with ranges, I had also thought of that at some point and was leaning towards doing that, but after the latest responses I think the arguments against it are sensible; and now there's a clear majority for keeping them separate. I'll be posting an updated version of the patch later today. I was a bit scared bit this part: On 2020-Mar-11, Paul A Jungwirth wrote: > Finally, I think I mentioned this a long time ago, but I'm still not > sure if this patch needs work around these things: > > - gist opclass > - spgist opclass > - typanalyze > - selectivity > > I'd love for a real Postgres expert to tell me "No, we can add that > later" or "Yes, you have to add that now." While I think that the gist and spgist opclass are in the "very nice to have but still optional" category, the other two items seem mandatory (but I'm not 100% certain about that, TBH). I'm not sure we have time to get those ready during this commitfest. ... thinking about gist+spgist, I think they could be written identically to those for ranges, using the lowest (first) lower bound and the higher (last) upper bound. ... thinking about selectivity, I think the way to write that is to first compute the selectivity for the range across the first lower bound and the last upper bound, and then subtract that for the "negative" space between the contained ranges. I have no immediate thoughts about typanalyze. I suppose it should be somehow based on the implementation for ranges ... maybe a first-cut is to construct fake ranges covering the whole multirange (as above) and just use the ranges implementation (compute_range_stats). -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
