[
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
compare 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.
was:
For non simple-aggregates, FilterAggregateTransposeRule's pushability check
compare column indices without taking into account column remapping from the
aggregate.
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
>
> For non simple-aggregates, FilterAggregateTransposeRule's pushability check
> compare 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
