Can you add your proposed fix to the bug, and we can discuss there.
> On May 21, 2021, at 2:33 AM, Vladimir Ozerov <ppoze...@gmail.com> wrote:
>
> Hi,
>
> I created two issues for two distinct bugs in AggregateUnionTransposeRule:
>
> 1. https://issues.apache.org/jira/browse/CALCITE-4616 - the problem with
> a partial Aggregate push-down
> 2. https://issues.apache.org/jira/browse/CALCITE-4615 - the problem with
> an incorrect type of aggregate call (not discussed in this thread before)
>
> Regarding issue 1, my proposal is to remove the partial pushdown
> optimization completely. We may do the following:
>
> 1. Iterate over all inputs, and check if they have a unique key on the
> Aggregate's group key.
> 2. If all inputs are unique, return as there is no sense to push the
> Aggregate past Union.
> 3. If at least one input is not unique, push aggregate to *all* inputs,
> to maintain the proper row type, assuming that the AggregateRemoveRule
> will eventually remove unnecessary aggregations.
>
> Regards,
> Vladimir.
>
> пт, 21 мая 2021 г. в 09:43, JiaTao Tao <taojia...@gmail.com>:
>
>> Sounds make sense
>>
>> Regards!
>>
>> Aron Tao
>>
>>
>> Vladimir Ozerov <ppoze...@gmail.com> 于2021年5月19日周三 下午8:57写道：
>>
>>> Hi,
>>>
>>> The AggregateUnionTransposeRule attempts to push the Aggregate below the
>>> Union.
>>>
>>> Before:
>>> Aggregate[group=$0, agg=SUM($1]
>>> Union[all]
>>> Input1
>>> Input2
>>>
>>> After:
>>> Aggregate[group=$0, agg=SUM($1]
>>> Union[all]
>>> Aggregate[group=$0, agg=SUM($1]
>>> Input1
>>> Aggregate[group=$0, agg=SUM($1]
>>> Input2
>>>
>>> When pushing the Aggregate, it checks whether the input is definitively
>>> unique on the grouping key. If yes, the Aggregate is not installed on top
>>> of the input, assuming that the result would be the same as without the
>>> Aggregate. This generates a type mismatch exception when aggregation is
>>> pushed only to some of the inputs:
>>> Aggregate[group=$0, agg=SUM($1]
>>> Union[all]
>>> Aggregate[group=$0, agg=SUM($1]
>>> Input1
>>> Input2
>>>
>>> It seems that the uniqueness check should not be in that rule at all, and
>>> the aggregate should be pushed unconditionally. Motivation: we already
>> have
>>> AggregateRemoveRule that removes unnecessary aggregates. No need to
>>> duplicate the same non-trivial logic twice.
>>>
>>> Does the proposal make sense to you?
>>>
>>> Regards,
>>> Vladimir.
>>>
>>
