feat(expr, agg): support PERCENTILE_CONT, PERCENTILE_DISC and MODE aggregation

[Honeta]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

percentile_cont ( fraction double precision ) WITHIN GROUP ( ORDER BY double precision ) → double precision

Computes the continuous percentile, a value corresponding to the specified fraction within the ordered set of aggregated argument values. This will interpolate between adjacent input items if needed.

percentile_disc ( fraction double precision ) WITHIN GROUP ( ORDER BY anyelement ) → anyelement

Computes the discrete percentile, the first value within the ordered set of aggregated argument values whose position in the ordering equals or exceeds the specified fraction. The aggregated argument must be of a sortable type.

mode () WITHIN GROUP ( ORDER BY anyelement ) → anyelement

Computes the mode, the most frequent value of the aggregated argument (arbitrarily choosing the first one if there are multiple equally-frequent values). The aggregated argument must be of a sortable type.

Only constant fraction arg is supported currently

Checklist For Contributors

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
• All checks passed in ./risedev check (or alias, ./risedev c)

Checklist For Reviewers

• I have requested macro/micro-benchmarks as this PR can affect performance substantially, and the results are shown.

Documentation

Click here for Documentation

Types of user-facing changes

Please keep the types that apply to your changes, and remove the others.

• SQL commands, functions, and operators

Release note

https://www.postgresql.org/docs/current/functions-aggregate.html#FUNCTIONS-ORDEREDSET-TABLE

[codecov]

Codecov Report

Merging #10252 (c3d9881) into main (353da76) will decrease coverage by 0.05%.
The diff coverage is 20.00%.

@@            Coverage Diff             @@
##             main   #10252      +/-   ##
==========================================
- Coverage   70.52%   70.47%   -0.05%     
==========================================
  Files        1244     1247       +3     
  Lines      213363   213548     +185     
==========================================
+ Hits       150473   150508      +35     
- Misses      62890    63040     +150     

Flag	Coverage Δ
rust	70.47% <20.00%> (-0.05%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/expr/src/agg/mod.rs	76.19% <ø> (ø)
src/expr/src/agg/percentile_disc.rs	1.85% <1.85%> (ø)
src/expr/src/agg/percentile_cont.rs	2.00% <2.00%> (ø)
src/expr/src/agg/mode.rs	2.04% <2.04%> (ø)
...rc/frontend/src/optimizer/plan_node/logical_agg.rs	96.66% <44.44%> (-0.42%)	⬇️
src/frontend/src/expr/agg_call.rs	73.94% <80.00%> (-0.41%)	⬇️
src/frontend/src/binder/expr/function.rs	86.28% <100.00%> (+0.35%)	⬆️

... and 5 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[stdrc]

LGTM!

[xiangjinwu]

The signature should be mode(*) -> auto, meaning the output is same as input. Using two * produces the Cartesian product of all combinations.

cc @wangrunji0408 Any ideas on preventing such misuses?

[st1page]

indeed, let me fix it.

[wangrunji0408]

It is valid and possible to have such a signature to make cartesian product, e.g. cast(*) -> *. So we can't forbid this usage. But it's possible to raise a warning in proc-macro and allow user to silence it if intended.