[
https://issues.apache.org/jira/browse/CALCITE-7779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Etienne Pelissier updated CALCITE-7779:
---------------------------------------
Description:
For non simple-aggregates, FilterAggregateTransposeRule's pushability check
compares column indices without taking into account column remapping from the
aggregate.
For instance, after applying AGGREGATE_PROJECT_MERGE followed by
FILTER_AGGREGATE_TRANSPOSE to:
{code:sql}
SELECT a, b
FROM (VALUES (0, 1, 2)) AS t(unused, a, b)
GROUP BY GROUPING SETS ((a), (a, b))
HAVING b IS NULL
{code}
The resulting plan is equivalent to:
{code:sql}
SELECT a, b
FROM (VALUES (0, 1, 2)) AS t(unused, a, b)
WHERE b IS NULL
GROUP BY GROUPING SETS ((a), (a, b))
{code}
which isn't semantically equivalent to the first query and returns different
results.
PS: I noticed that the [developer guide|https://calcite.apache.org/develop/]
doesn't clearly state what the GitHub PR description template states:
The following three items MUST match exactly in wording and meaning:
(A) The Jira Issue Title
(B) This Pull Request Title
(C) Your Git Commit Message
was:
For non simple-aggregates, FilterAggregateTransposeRule's pushability check
compares column indices without taking into account column remapping from the
aggregate.
For instance, after applying AGGREGATE_PROJECT_MERGE followed by
FILTER_AGGREGATE_TRANSPOSE to:
{code:sql}
SELECT a, b
FROM (VALUES (0, 1, 2)) AS t(unused, a, b)
GROUP BY GROUPING SETS ((a), (a, b))
HAVING b IS NULL
{code}
The resulting plan is equivalent to:
{code:sql}
SELECT a, b
FROM (VALUES (0, 1, 2)) AS t(unused, a, b)
WHERE b IS NULL
GROUP BY GROUPING SETS ((a), (a, b))
{code}
which isn't semantically equivalent to the first query and returns different
results.
> Optimization rule FilterAggregateTransposeRule rewrites queries to
> semantically non-equivalent ones
> ---------------------------------------------------------------------------------------------------
>
> Key: CALCITE-7779
> URL: https://issues.apache.org/jira/browse/CALCITE-7779
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Etienne Pelissier
> Assignee: Etienne Pelissier
> Priority: Major
> Labels: pull-request-available
>
> For non simple-aggregates, FilterAggregateTransposeRule's pushability check
> compares column indices without taking into account column remapping from the
> aggregate.
> For instance, after applying AGGREGATE_PROJECT_MERGE followed by
> FILTER_AGGREGATE_TRANSPOSE to:
> {code:sql}
> SELECT a, b
> FROM (VALUES (0, 1, 2)) AS t(unused, a, b)
> GROUP BY GROUPING SETS ((a), (a, b))
> HAVING b IS NULL
> {code}
> The resulting plan is equivalent to:
> {code:sql}
> SELECT a, b
> FROM (VALUES (0, 1, 2)) AS t(unused, a, b)
> WHERE b IS NULL
> GROUP BY GROUPING SETS ((a), (a, b))
> {code}
> which isn't semantically equivalent to the first query and returns different
> results.
> PS: I noticed that the [developer guide|https://calcite.apache.org/develop/]
> doesn't clearly state what the GitHub PR description template states:
> The following three items MUST match exactly in wording and meaning:
> (A) The Jira Issue Title
> (B) This Pull Request Title
> (C) Your Git Commit Message
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
