AggregateUnionTransposeRule fails when some inputs have unique grouping key

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

AggregateUnionTransposeRule fails when some inputs have unique grouping key

Vladimir Ozerov-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: AggregateUnionTransposeRule fails when some inputs have unique grouping key

Pavel Tupitsyn
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.
>
Reply | Threaded
Open this post in threaded view
|

Re: AggregateUnionTransposeRule fails when some inputs have unique grouping key

Vladimir Ozerov-2
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.
> >
>