feat: decimal support for percentile_cont and median by theirix · Pull Request #24419 · apache/datafusion

theirix · 2026-08-16T22:56:25Z

Which issue does this PR close?

Closes Align median and percentile_cont implementations (preserve Decimal in percentile_cont, alias median) #22042.

Rationale for this change

UDF percentile_cont uses floating-point arithmetic to find a percentile, which doesn't work well for decimals. The median UDF already supports decimals. Let's implement decimals in percentile_cont and build median on top of it.

A follow-up to #21988, refines #23954.

What changes are included in this PR?

Exact decimal support for percentile_cont, without float coercion
Linear interpolation for both float (old code) and decimal code paths (new code)
Implement median on top of percentile_cont UDF by prepending a 0.5f argument
Add SLTs to verify code
Make percentile_cont(NULL) return NULL (see changes below), under a new SLT test case
Tuned test_oom to call UDF directly with float parameters (it used integers before without adhering to coercion rules)

Are these changes tested?

Extend SLTs
Unit tests for percentile_cont

Are there any user-facing changes?

percentile_cont(NULL) now returns a NULL type instead of a Float64 type, aligning with other aggregate UDFs

codecov-commenter · 2026-08-16T23:21:44Z

Codecov Report

❌ Patch coverage is 90.29126% with 20 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.33%. Comparing base (bbf739a) to head (cf72d19).
⚠️ Report is 61 commits behind head on main.

Files with missing lines	Patch %	Lines
...afusion/functions-aggregate/src/percentile_cont.rs	89.52%	7 Missing and 13 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #24419      +/-   ##
==========================================
+ Coverage   81.23%   81.33%   +0.09%     
==========================================
  Files        1111     1117       +6     
  Lines      390208   396050    +5842     
  Branches   390208   396050    +5842     
==========================================
+ Hits       316990   322113    +5123     
- Misses      54591    55101     +510     
- Partials    18627    18836     +209

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

theirix · 2026-08-16T23:25:24Z

CC @neilconway

Jefffrey

Integer support for percentile_cont (backported from median UDF)

this doesnt sound right, since this is continuous and not discrete so it must always be a float (or decimal)

Jefffrey · 2026-08-18T01:48:30Z

 #[derive(PartialEq, Eq, Hash, Debug)]
 pub struct Median {
    signature: Signature,
+    percentile_cont: PercentileCont,


i do wonder if we should implement simplify for median to make it an unconditional rewrite to percentile_cont

We've done forwarding calls to a child UDF before in other functions. I can try a rewrite approach and tell if it is more concise - I thought it could hurt programmatic usage in tests (like the mentioned test_oom)

Well, I've tried, but the simplifier has a flaw with the window aggregation functions (median(x) OVER ) - it is unable to call a simplifier and just falls back to a normal UDAF accumulator, making the rewrite irrelevant.

This could be a reason why approx_percentile_cont doesn't do rewrites either. I can try fixing these simplifier bugs later.

4. query failed: DataFusion error: Internal error: median accumulator should have been simplified to standard percentile_cont. This issue was likely caused by a bug in DataFusion's code. Please help us to resolve this by filing a bug report in our issue tracker: https://github.com/apache/datafusion/issues [SQL] SELECT timestamp, tags, value, median(DISTINCT value) OVER ( PARTITION BY tags ORDER BY timestamp ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS distinct_median FROM median_window_test ORDER BY tags, timestamp; at /Users/irix/projects/third-party/datafusion/datafusion/sqllogictest/test_files/aggregate.slt:1080

With median distinct, it is also failing with some conflicting optimisation with group by - the plan omits grouping entirely

[SQL] explain select median(distinct c) from t; [Diff] (-expected|+actual) logical_plan - 01)Projection: median(alias1) AS median(DISTINCT t.c) - 02)--Aggregate: groupBy=[[]], aggr=[[median(alias1)]] - 03)----Aggregate: groupBy=[[CAST(t.c AS Float64) AS alias1]], aggr=[[]] - 04)------TableScan: t projection=[c] + 01)Aggregate: groupBy=[[]], aggr=[[percentile_cont(DISTINCT CAST(t.c AS Float64), Float64(0.5)) AS median(DISTINCT t.c)]] + 02)--TableScan: t projection=[c] physical_plan - 01)ProjectionExec: expr=[median(alias1)@0 as median(DISTINCT t.c)] - 02)--AggregateExec: mode=Final, gby=[], aggr=[median(alias1)] - 03)----CoalescePartitionsExec - 04)------AggregateExec: mode=Partial, gby=[], aggr=[median(alias1)] - 05)--------AggregateExec: mode=FinalPartitioned, gby=[alias1@0 as alias1], aggr=[] - 06)----------RepartitionExec: partitioning=Hash([alias1@0], 4), input_partitions=1 - 07)------------AggregateExec: mode=Partial, gby=[CAST(c@0 AS Float64) as alias1], aggr=[] - 08)--------------DataSourceExec: partitions=1, partition_sizes=[1] + 01)AggregateExec: mode=Single, gby=[], aggr=[percentile_cont(DISTINCT t.c, 0.5) as median(DISTINCT t.c)] + 02)--DataSourceExec: partitions=1, partition_sizes=[1] at /Users/irix/projects/third-party/datafusion/datafusion/sqllogictest/test_files/aggregate.slt:1502

So, in the middle ground, I refactored the code a bit to avoid schema twiddling in median - now we just create accumulators explicitly, and it looks more concise.

thanks for checking; the udaf simplifier does seem a bit more tricky to work with compared to udf 🤔

Jefffrey · 2026-08-20T02:34:41Z

+struct DecimalInterpolator;
+
+/// Precision multiplier for decimal linear interpolation calculations.
+fn deduce_interpolation_precision<T: DecimalType>() -> usize {


is there specific reasoning chosen for these values?

The first constant 10000 is chosen for Decimal32 with 4-byte native type specifically so that scale_by_num doesn't overflow when computing a decomposition. The second one is just the same as FLOAT_INTERPOLATION_PRECISION - I can reuse the same value for clarity

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

for reference too, from duckdb:

memory D select percentile_cont(0.00009) within group (order by v) from values (0::decimal(9,0)), (999999999::decimal(9,0)) t(v); ┌───────────────────────────────────┐ │ quantile_cont(0.00009 ORDER BY v) │ │ decimal(9,0) │ ├───────────────────────────────────┤ │ 89999 │ └───────────────────────────────────┘

It's a good catch. Let me also generate some edge cases from other DB codebases as well (and especially for smaller decimals), and I'll return in a follow-up PR

theirix added 3 commits August 16, 2026 23:31

Exact decimal support for percentile_cont

262cd7b

Implement median UDF via percentile_cont

b01061d

Update SLTs for percentile_cont, median

5bf1a0e

github-actions Bot added sqllogictest SQL Logic Tests (.slt) functions Changes to functions implementation labels Aug 16, 2026

theirix marked this pull request as ready for review August 16, 2026 23:24

Add SLTs for percentile_cont to cover more cases

df896d2

Jefffrey reviewed Aug 18, 2026

View reviewed changes

theirix added 4 commits August 18, 2026 22:21

Use new API new_implicit_native

89d9c1c

Always verify percentiles

df8b97d

Switch test_oom support to use signature int type for median

c12d23d

Remove non-continous integer code path

041a236

github-actions Bot added the physical-plan Changes to the physical-plan crate label Aug 19, 2026

Jefffrey reviewed Aug 20, 2026

View reviewed changes

theirix added 2 commits August 20, 2026 23:20

Create accumulators directly in median

3e35a7f

Reuse the same scaling constant for float and decimal

cf72d19

Jefffrey approved these changes Aug 21, 2026

View reviewed changes

Uh oh!

Conversation

theirix commented Aug 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

codecov-commenter commented Aug 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

theirix commented Aug 16, 2026

Uh oh!

Jefffrey left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Jefffrey Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

theirix commented Aug 16, 2026 •

edited

Loading

codecov-commenter commented Aug 16, 2026 •

edited

Loading

Jefffrey Aug 21, 2026 •

edited

Loading