You have definitely found a bug. One solution is to remove some of the rule’s responsibilities - delegating to another rule that presumably doesn’t have the bug. That would be a breaking change. Another solution is to fix the rule.
Please log a jira case, and let’s discuss further there. Reading the code, I noticed that it only pushes down if the UNION has ALL. I think it could push down through a UNION DISTINCT if there are no aggregate functions. Let’s consider that as an enhancement. Julian > On May 19, 2021, at 5:57 AM, Vladimir Ozerov <ppoze...@gmail.com> wrote: > > 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.
