public inbox for [email protected]
help / color / mirror / Atom feedFrom: SCHOEMANS Maxime <[email protected]>
To: Haibo Yan <[email protected]>
Cc: vignesh C <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Damir Belyalov <[email protected]>
Cc: jian he <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: SAKR Mahmoud <[email protected]>
Cc: Diogo Repas <[email protected]>
Cc: Andrey Lepikhov <[email protected]>
Subject: Re: Implement missing join selectivity estimation for range types
Date: Wed, 15 Apr 2026 15:13:34 +0000
Message-ID: <DB8P190MB0731EA1B8381F48AA15B9437F0222@DB8P190MB0731.EURP190.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CABXr29Gts+FuMRkeA=JNAxB700W1EQW2F=W2wAjtJrGZDGTxGw@mail.gmail.com>
References: <CAB4o4asMq3k6HN9WfDsssQ5DDVfAziB4TpiFJ8RBJgZTVuwC7g@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAB4o4aud47V_iRyWtA8+ZAmdXDjCF165R73AeCjx2RL0nzQzHA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAB4o4asvPN=NT7KvS9zVQjZbdsiRW5t8aQctEkW7mxc4hbBxVQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CALH1Lgurg1y1DTeFOXOkpP=+X7saVGCh8gSjDLoCBOcFFWhz-A@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CALDaNm29NMhpPvoM49qqfYzVcRJq0CPTd-xSUcTF7RZQO2TASQ@mail.gmail.com>
<[email protected]>
<CALDaNm3A4j7=rmY128Eb3v8zi=hHAnGizUcbSX5ekZKHy-wmMA@mail.gmail.com>
<CACJufxFhES7untAPmxJDrB-y_pNgah_1HNbXjcOj6g=yxh3kdA@mail.gmail.com>
<CABXr29HUT2m7YPpB4gOZHphYmwpwuEWFZ_p6oeyouhWw8Zc1Tw@mail.gmail.com>
<DB8P190MB0731FF1A358E9AB16FB1F14FF0252@DB8P190MB0731.EURP190.PROD.OUTLOOK.COM>
<CABXr29Gts+FuMRkeA=JNAxB700W1EQW2F=W2wAjtJrGZDGTxGw@mail.gmail.com>
Hi Haibo,
Thank you for the review.
> One small note: the localized bool join_is_reversed; in my version was
> intentional. I left it that way because get_join_variables() wants a
> storage location, and I preferred to keep that use local and explicit
> rather than trying to reshape things around it.
Fair point. I moved it out of the bare block because it looked unusual,
but I can change it back if you prefer.
> For patch 2, I am less convinced, especially for &&.
> [...]
> for multiranges there is a third possibility: neither side is entirely
> left nor entirely right, and yet they still do not overlap because of
> an internal gap.
This is a valid concern, but it is an existing limitation of multirange
statistics, not something we are introducing. The existing restriction
selectivity code in multirangetypes_selfuncs.c already uses the same
NOT(<<) AND NOT(>>) decomposition for && on multiranges. And
multirange_typanalyze explicitly says:
/* Treat multiranges like a big range without gaps. */
The statistics only store the outermost bounds, so the gap information
is already lost before our estimator sees it. The multirange GiST
opclass does the same (stores the bounding range). Our join estimator
is just consistent with how multiranges are handled elsewhere.
The alternative is falling back to the 0.005 default, which will almost
certainly be worse. Would a comment explaining the limitation be enough?
> For patch 3, I agree with the motivation [...] But I am not convinced
> that exporting those helpers via selfuncs.h is the right boundary.
> My preference would be something tighter: [...] a backend-private
> internal header just for the range-family selfuncs code
Good point about the visibility. I'll move the declarations to a
separate backend-private header in the next version.
Regards,
Maxime
view thread (16+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Implement missing join selectivity estimation for range types
In-Reply-To: <DB8P190MB0731EA1B8381F48AA15B9437F0222@DB8P190MB0731.EURP190.PROD.OUTLOOK.COM>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox