Maksim Zhuravkov created IGNITE-21838:
-----------------------------------------
Summary: Sql. Provide correct type information for intermediate
results of a MAP aggregate
Key: IGNITE-21838
URL: https://issues.apache.org/jira/browse/IGNITE-21838
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Maksim Zhuravkov
We need to introduce means to expose intermediate type of MAP aggregate, to
make it is possible to construct a correctly typed plan w/o special casing
DECIMAL type that return a correct type / or fix Accumulator::returnType.
----
A brief overview of current implementation of accumulators in the sql engine.
AggregateCall: logical aggregate
AggregateCall: Func(ArgType) -> RetType
Accumulator: implementation of a logical aggregate
Accumulator: FuncImpl(RunArgType) -> RunRetType
Two-phase aggregate implementation:
{code:java}
MAP
runArg = CAST(arg of type ArgType TO RunArgType)
mapRes = MapFuncImpl(runArg)
return mapRes // !!! No type transformation here, returns RunArgType or a type
returned by MapFuncImpl
REDUCE
runArg = arg // mapRes w/o casting
reduceRes = ReduceFuncImpl(runArg)
return CAST(reduceRes of type ReduceFuncImpl's result to RetType)
{code}
An acute observer can see a problem here, when an aggregate is split into
functions that produce results of different type there is a type mismatch
between MAP and REDUCE.
This mismatch is currently fixed in PlanUtil::create*AggRowType, via call to
Accumulator::returnType. But this method does not provide correct / precision
and scale.
P.S.
This mismatch can not be fixed via built-in projection, because it type checks
its input (so it is rejects handcrafted input-refs that return types that are
correct according to AI-3 logic, but aren't corroding to actual relational
operators).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
