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