Repository navigation
percentile_cont is wrong for Decimal32 with lower interpolation precision #24576
Description
Describe the bug
A follow-up for #24419, which introduced pure-decimal interpolation, where a smaller interpolation precision was used for Decimal32 types with Euclidean interpolation. Seems like, a smaller precision for Decimal32 is not enough, and we have to widen i32 inputs to i64 to handle edge cases
To Reproduce
@Jefffrey noted:
I mainly ask since i had codex check some of the math and it mentioned some edge cases where the wrong value can be returned, for example:
> SELECT percentile_cont(0.00009) WITHIN GROUP (ORDER BY v)
FROM (VALUES (arrow_cast(0, 'Decimal32(9,0)')), (arrow_cast(999999999, 'Decimal32(9,0)'))) as t (v);
+---------------------------------------------------------------------+
| percentile_cont(Float64(0.00009)) WITHIN GROUP [t.v ASC NULLS LAST] |
+---------------------------------------------------------------------+
| 0 |
+---------------------------------------------------------------------+
1 row(s) fetched.
Elapsed 0.010 seconds.this is only for decimal32, decimal64 & above seems fine. for reference, if done on float:
> SELECT percentile_cont(0.00009) WITHIN GROUP (ORDER BY v)
FROM (VALUES (0), (999999999)) as t (v);
+---------------------------------------------------------------------+
| percentile_cont(Float64(0.00009)) WITHIN GROUP [t.v ASC NULLS LAST] |
+---------------------------------------------------------------------+
| 89999.99991 |
+---------------------------------------------------------------------+
1 row(s) fetched.
Elapsed 0.010 seconds.i havent looked too closely at the interpolation maths, but i wonder if this is something we should try fix if possible? or can do in followup
Expected behavior
The mentioned query should provide 89999.99991 as with duckdb
Additional context
No response
Activity
theirix commentedon Aug 22, 2026
take
feat: widen percentile input to use larger precision (apache#24577)