Re: Implement missing join selectivity estimation for range types

On Thu, Apr 16, 2026 at 8:13 AM SCHOEMANS Maxime <maxime(dot)schoemans(at)ulb(dot)be>
wrote:

> Hi Haibo,
>
> Attached is v7 with the changes we discussed.
>
> Patch 2 now has an inline comment on the && case explaining the
> outer-bounds approximation and its consistency with existing restriction
> selectivity. The commit message mentions it as well.
>
> Patch 3 uses a separate backend-private header (rangetypes_selfuncs.h)
> instead of selfuncs.h.
>
> Regards,
> Maxime
>

Hi Maxime,

Thanks for the updated series. Overall I do not have major objections to
the direction here.

A few small nits on patch 2:

1. In the commit message, I wonder if “the core algorithm is identical”
is a bit stronger than necessary. Since the main point is that we are
reusing the same approximation based on outer bounds, something like “the
same outer-bounds-based estimator can be reused” might be a bit more
precise.
2. In a few comments, the wording still says just “range”, but in patch
2 we are really dealing with range/multirange combinations. I think it
would be a bit clearer to make that explicit where appropriate, and reserve
“range” for the underlying range-type/bound-comparison level.
3. I think it would be good to add the reverse mixed-direction test as
well, since patch 2 covers multirange × range in addition to range ×
multirange. Something like:

--------------------------------------------------------
explain (costs off)
select count(*)
from test_mr_join_mr a, test_mr_join_r b
where a.mr << b.r;

explain (costs off)
select count(*)
from test_mr_join_mr a, test_mr_join_r b
where a.mr >> b.r;

explain (costs off)
select count(*)
from test_mr_join_mr a, test_mr_join_r b
where a.mr && b.r;
--------------------------------------------------------

I think that would make the mixed-case coverage feel more complete.

Regards,
Haibo