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. |
Hi Vladimir,
Looks like this message is for [hidden email], not [hidden email], or am I mistaken? On Wed, May 19, 2021 at 2:25 PM Vladimir Ozerov <[hidden email]> 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. > |
Hi Pavel,
Yes, I missed the list, sorry. ср, 19 мая 2021 г. в 14:40, Pavel Tupitsyn <[hidden email]>: > Hi Vladimir, > > Looks like this message is for [hidden email], not > [hidden email], > or am I mistaken? > > On Wed, May 19, 2021 at 2:25 PM Vladimir Ozerov <[hidden email]> > 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. > > > |
Free forum by Nabble | Edit this page |