Details
Description
Motivation
As for now we have custom code that splits aggregate function into map-reduce stages. See class/method usage for details:
MapReduceAggregates.buildAggregates
Some functions (e.g. AVG) are split into 2 functions which may have incompatible types (e.g. COUNT returns BIGINT on map-phase, but SUM on reduce-phase requires DECIMAL).
This forces adding a Projection in between, but this additional stage looks synthetic and rises costs.
I've found Calcite already have `AggregateReduceFunctionsRule`, which splits functions in different way (using `CASE-WHEN` clause instead of Project), and can be reused.
Suggestion
Let's try to reuse Calcite rule and/or splitting functions, and drop duplicating code from our codebase.
Otherwise, if there are obstacles, go the similar way at least.
Fix planner tests, which expects a Project between map and reduce phases.
Expectation
After this fix, we should observe no projection in between map and reduce aggregate phases.
Attachments
Issue Links
- is caused by
-
IGNITE-20009 Sql. Rework 2-phase aggregates part 2. AVG as SUM / COUNT.
- Resolved
- is related to
-
IGNITE-21838 Sql. Provide correct type information for intermediate results of MAP aggregates
- Open
- relates to
-
IGNITE-21580 Sql. Unable to optimise query using only two phase aggregates
- Resolved