Re: Implement missing join selectivity estimation for range types - Mailing list pgsql-hackers

From Haibo Yan
Subject Re: Implement missing join selectivity estimation for range types
Date
Msg-id CABXr29HNiiDo9nU-iOgLgWjg_MS=ZheSaq+Waf2i5FDy4GL1rg@mail.gmail.com
Whole thread
In response to Re: Implement missing join selectivity estimation for range types  (SCHOEMANS Maxime <maxime.schoemans@ulb.be>)
Responses Re: Implement missing join selectivity estimation for range types
List pgsql-hackers
On Thu, Apr 16, 2026 at 8:13 AM SCHOEMANS Maxime <maxime.schoemans@ulb.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

pgsql-hackers by date:

Previous
From: Tatsuya Kawata
Date:
Subject: [PATCH] Doc: Fix missing func_signature role in pg_get_tablespace_ddl entry
Next
From: Xuneng Zhou
Date:
Subject: Re: test: avoid redundant standby catchup in 049_wait_for_lsn