Apache Cloudberry version
main branch (recent build, assert-enabled)
What happened
On an assert-enabled build, the planner (not ORCA) hits an assertion in join size estimation when an OR clause mixes a predicate on the outer side of a LEFT JOIN with a range predicate on the nullable inner side:
FailedAssertion("pselec >= 0.0 && pselec <= 1.0", costsize.c:5506)
The assertion is the last line of adjust_selectivity_for_nulltest(), which is Cloudberry-specific code called from calc_joinrel_size_estimate() under gp_adjust_selectivity_for_outerjoins (default on). Upstream PostgreSQL has no equivalent assertion. pselec comes from clauselist_selectivity() on the pushed-down OR clause and is already outside [0, 1] before the null-test adjustment (which does not fire here since the clause is a BoolExpr). Which sub-term produces the out-of-range value has not been narrowed down yet. On a non-assert build this silently produces a bad row estimate instead of crashing. Line number is from current main.
Found by SQLancer.
What you think should happen instead
The selectivity should stay within [0, 1] and the query should return a count without crashing.
How to reproduce
CREATE TABLE m1(c0 inet);
CREATE TABLE m2(c0 inet);
INSERT INTO m2 VALUES ('88.147.138.141'), ('76.163.212.11'), ('214.10.65.144');
ANALYZE m1, m2;
SELECT COUNT(*) FROM ONLY m1 LEFT OUTER JOIN m2 ON true
WHERE (m1.c0 IS NOT NULL)
OR (m2.c0 BETWEEN SYMMETRIC '75.175.243.19' AND '230.9.216.68');
-- FailedAssertion("pselec >= 0.0 && pselec <= 1.0", costsize.c:5506)Operating System
Linux
Anything else
Found while running SQLancer against Cloudberry main (3-segment demo cluster, --enable-cassert). See the proposal to run SQLancer continuously: #1952
Are you willing to submit PR?
Code of Conduct
Apache Cloudberry version
main branch (recent build, assert-enabled)
What happened
On an assert-enabled build, the planner (not ORCA) hits an assertion in join size estimation when an OR clause mixes a predicate on the outer side of a LEFT JOIN with a range predicate on the nullable inner side:
The assertion is the last line of
adjust_selectivity_for_nulltest(), which is Cloudberry-specific code called fromcalc_joinrel_size_estimate()undergp_adjust_selectivity_for_outerjoins(default on). Upstream PostgreSQL has no equivalent assertion.pseleccomes fromclauselist_selectivity()on the pushed-down OR clause and is already outside [0, 1] before the null-test adjustment (which does not fire here since the clause is a BoolExpr). Which sub-term produces the out-of-range value has not been narrowed down yet. On a non-assert build this silently produces a bad row estimate instead of crashing. Line number is from currentmain.Found by SQLancer.
What you think should happen instead
The selectivity should stay within [0, 1] and the query should return a count without crashing.
How to reproduce
Operating System
Linux
Anything else
Found while running SQLancer against Cloudberry
main(3-segment demo cluster,--enable-cassert). See the proposal to run SQLancer continuously: #1952Are you willing to submit PR?
Code of Conduct