Repository navigation
[Bug] width_bucket returns 0 when num_buckets > (max_value - min_value) #68222
Description
Search before asking
- I had searched in the issues and found no similar issues.
Version
master
CommitID: 979e053
What's Wrong?
mysql> select width_bucket (9, 0, 10, 20);
+-----------------------------+
| width_bucket (9, 0, 10, 20) |
+-----------------------------+
| 0 |
+-----------------------------+
1 row in set (0.02 sec)
mysql> select width_bucket (3, 0, 10, 20);
+-----------------------------+
| width_bucket (3, 0, 10, 20) |
+-----------------------------+
| 0 |
+-----------------------------+
1 row in set (0.02 sec)
mysql> select width_bucket (1, 0, 2, 5);
+---------------------------+
| width_bucket (1, 0, 2, 5) |
+---------------------------+
| 0 |
+---------------------------+
1 row in set (0.01 sec)
mysql> select width_bucket (0, 0, 10, 20);
+-----------------------------+
| width_bucket (0, 0, 10, 20) |
+-----------------------------+
| 0 |
+-----------------------------+
1 row in set (0.02 sec)
What You Expected?
mysql> select width_bucket (9, 0, 10, 20);
+-----------------------------+
| width_bucket (9, 0, 10, 20) |
+-----------------------------+
| 19 |
+-----------------------------+
1 row in set (0.02 sec)
mysql> select width_bucket (3, 0, 10, 20);
+-----------------------------+
| width_bucket (3, 0, 10, 20) |
+-----------------------------+
| 7 |
+-----------------------------+
1 row in set (0.02 sec)
mysql> select width_bucket (1, 0, 2, 5);
+---------------------------+
| width_bucket (1, 0, 2, 5) |
+---------------------------+
| 3 |
+---------------------------+
1 row in set (0.01 sec)
mysql> select width_bucket (0, 0, 10, 20);
+-----------------------------+
| width_bucket (0, 0, 10, 20) |
+-----------------------------+
| 1 |
+-----------------------------+
1 row in set (0.02 sec)
How to Reproduce?
Run the following SQL directly (no table required):
select width_bucket(9, 0, 10, 20); -- returns 0
select width_bucket(3, 0, 10, 20); -- returns 0
select width_bucket(1, 0, 2, 5); -- returns 0
All three should return 19 / 7 / 3 respectively.
Anything Else?
No response
Are you willing to submit PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
Doris-Breakwater commentedon Sep 19, 2026
Breakwater-GitHub-Analysis-Slot: slot_5b7a1add75c6
Initial assessment
This is a confirmed deterministic correctness bug in the BE
width_bucketimplementation at commit979e053f0802fbc48f83dafe7f713c02968415a8. The issue is currently open with no labels; the supplied commit and scalar SQL are sufficient for initial triage.Verified root cause
In
FunctionWidthBucket::_execute,average_valueis correctly computed with floating-point arithmetic:However, the in-range branch then checks the width again using the input type's arithmetic:
For the integral overloads, this is integer division. For example,
10 / 20and2 / 5truncate to0;continueleaves the pre-zeroed result unchanged. That directly explains every reported result, includingwidth_bucket(0, 0, 10, 20): an expression equal to the lower bound reaches the stale guard and incorrectly remains bucket0instead of bucket1.The confirmed scope is the
TINYINT,SMALLINT,INT, andBIGINTexecution paths when0 < max_value - min_value < num_bucketsand the expression is in[min_value, max_value). Values belowmin_valueand values at/abovemax_valuetake earlier branches and are not affected by this guard. The same integer-truncation mechanism does not apply to the floating-point overloads.History supports this diagnosis: the guard protected the original integer denominator. PR #24673 changed the actual bucket calculation to divide by the floating-point
average_value, but retained the old integer zero check. Existing regression coverage also misses this shape: the direct integer case uses a span of 11 with 10 buckets, while the generated integral cases use a span of 1 with 1 bucket.Missing information
No additional logs, profile, or environment details are required to establish this issue. The version, exact commit, deterministic reproduction, and expected values are all present. I did not run a Doris cluster or a candidate patch during this triage; the conclusion is based on the reported runtime output and inspection of the exact commit.
Recommended next steps
average_value. Keep the existing below-range (0) and at/above-range (num_buckets + 1) behavior unchanged.test_width_bucket_function.groovy, including the lower-bound case.expr = min_value, an in-range value nearmax_value, and the existing out-of-range boundaries. This prevents the fix from only covering the literal type selected by the analyzer.test_width_bucket_functionregression suite and the existing Nereids scalar-function coverage before merge.The fix direction above is code-derived but has not yet been implemented or test-validated here. Equal or descending bounds are outside the reported failure and should not have their semantics changed incidentally.