You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Vladimir Ozerov <pp...@gmail.com> on 2021/05/19 11:24:05 UTC

AggregateUnionTransposeRule fails when some inputs have unique grouping key

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.

Re: AggregateUnionTransposeRule fails when some inputs have unique grouping key

Posted by Vladimir Ozerov <pp...@gmail.com>.
Hi Pavel,

Yes, I missed the list, sorry.

ср, 19 мая 2021 г. в 14:40, Pavel Tupitsyn <pt...@apache.org>:

> Hi Vladimir,
>
> Looks like this message is for dev@calcite.apache.org, not
> dev@ignite.apache.org,
> or am I mistaken?
>
> On Wed, May 19, 2021 at 2:25 PM Vladimir Ozerov <pp...@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.
> >
>

Re: AggregateUnionTransposeRule fails when some inputs have unique grouping key

Posted by Pavel Tupitsyn <pt...@apache.org>.
Hi Vladimir,

Looks like this message is for dev@calcite.apache.org, not
dev@ignite.apache.org,
or am I mistaken?

On Wed, May 19, 2021 at 2:25 PM Vladimir Ozerov <pp...@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.
>