Repository navigation
Use range transformation information to avoid aggregate repartitioning #25345
Description
Is your feature request related to a problem or challenge?
Grouped aggregation currently inserts a hash RepartitionExec when grouping by date_bin or date_trunc over a range-partitioned input, even when the existing partitioning keeps each group local to one input partition.
#25344 establishes how functions expose that they support range-partitioning analysis, but the partition-satisfaction and aggregation-planning logic must use that information before the unnecessary repartition can be removed.
Describe the solution you'd like
Use the range-transformation information exposed by #25344 to determine when the existing range partitioning keeps each group local to one input partition.
When that guarantee holds, allow grouped aggregation to use the existing range partitioning instead of inserting a hash RepartitionExec.
Grouped aggregation will be the first consumer, but the underlying range information should remain usable by other operators in future work.
Activity
benbellick commentedon Sep 15, 2026
take
benbellick commentedon Sep 19, 2026
For the initial implementation I'll start with single-key range partitioning. It shouldn't be hard to add compound range keys, but I want to minimize what will probably be a fairly large PR.
feat: reuse range partitioning for date_trunc aggregation (apache#26449)
fix(datetime): error on out-of-range date_bin timestamp bins (apache#…
feat: reuse range partitioning for audited date_bin aggregation (apac…