[
https://issues.apache.org/jira/browse/CALCITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-5553:
---------------------------------
Description:
A Beam user brought us a query that produces an invalid plan after
upgrading to a newer version of Beam (moving them from Calcite 1.20 to
1.28). I was able to write a test case which demonstrates this issue
with a trivial filter on a table containing a nested struct with a
single field. The issue appears to be coming out of
RelStructuredTypeFlattener.rewrite and I bisected it to a single
commit,
[e44beba28|https://github.com/apache/calcite/commit/e44beba286ea9049c5fd00c3a3b0e4a4f1c03356].
Removing the noFlatteningForInput function added in this commit fixes
the issue. That method doesn't appear to be looking at types at all,
only mismatches in field count, I expect so any single field struct
would hit this. Any suggestions on how we can work around this in
Beam?
The test query and plans are as follows, the test case is in [PR
3092|https://github.com/apache/calcite/pull/3092].
{code}
select dn.skill from sales.dept_single dn WHERE dn.skill.type = ''
{code}
Expected plan:
{noformat}
LogicalProject(SKILL=[ROW($0)])
LogicalFilter(condition=[=($0, '')])
LogicalProject(TYPE=[$0.TYPE])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
{noformat}
Actual Plan:
{noformat}
LogicalProject(SKILL=[ROW($0)])
LogicalFilter(condition=[=($0.TYPE, '')])
LogicalProject(TYPE=[$0.TYPE])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
{noformat}
Plan before flatten:
{noformat}
LogicalProject(SKILL=[$0])
LogicalFilter(condition=[=($0.TYPE, '')])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
{noformat}
was:
A Beam user brought us a query that produces an invalid plan after
upgrading to a newer version of Beam (moving them from Calcite 1.20 to
1.28). I was able to write a test case which demonstrates this issue
with a trivial filter on a table containing a nested struct with a
single field. The issue appears to be coming out of
RelStructuredTypeFlattener.rewrite and I bisected it to a single
commit:
https://github.com/apache/calcite/commit/e44beba286ea9049c5fd00c3a3b0e4a4f1c03356
Removing the noFlatteningForInput function added in this commit fixes
the issue. That method doesn't appear to be looking at types at all,
only mismatches in field count, I expect so any single field struct
would hit this. Any suggestions on how we can work around this in
Beam?
The test query and plans are as follows, the test case is here
https://github.com/apache/calcite/pull/3092
select dn.skill from sales.dept_single dn WHERE dn.skill.type = ''
Expected plan:
LogicalProject(SKILL=[ROW($0)])
LogicalFilter(condition=[=($0, '')])
LogicalProject(TYPE=[$0.TYPE])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
Actual Plan:
LogicalProject(SKILL=[ROW($0)])
LogicalFilter(condition=[=($0.TYPE, '')])
LogicalProject(TYPE=[$0.TYPE])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
Plan before flatten:
LogicalProject(SKILL=[$0])
LogicalFilter(condition=[=($0.TYPE, '')])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
> Calcite RelStructuredTypeFlattener produces bad plan for single field structs
> -----------------------------------------------------------------------------
>
> Key: CALCITE-5553
> URL: https://issues.apache.org/jira/browse/CALCITE-5553
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.23.0, 1.28.0, 1.33.0
> Reporter: Andrew Pilloud
> Priority: Major
>
> A Beam user brought us a query that produces an invalid plan after
> upgrading to a newer version of Beam (moving them from Calcite 1.20 to
> 1.28). I was able to write a test case which demonstrates this issue
> with a trivial filter on a table containing a nested struct with a
> single field. The issue appears to be coming out of
> RelStructuredTypeFlattener.rewrite and I bisected it to a single
> commit,
> [e44beba28|https://github.com/apache/calcite/commit/e44beba286ea9049c5fd00c3a3b0e4a4f1c03356].
> Removing the noFlatteningForInput function added in this commit fixes
> the issue. That method doesn't appear to be looking at types at all,
> only mismatches in field count, I expect so any single field struct
> would hit this. Any suggestions on how we can work around this in
> Beam?
> The test query and plans are as follows, the test case is in [PR
> 3092|https://github.com/apache/calcite/pull/3092].
> {code}
> select dn.skill from sales.dept_single dn WHERE dn.skill.type = ''
> {code}
> Expected plan:
> {noformat}
> LogicalProject(SKILL=[ROW($0)])
> LogicalFilter(condition=[=($0, '')])
> LogicalProject(TYPE=[$0.TYPE])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
> {noformat}
> Actual Plan:
> {noformat}
> LogicalProject(SKILL=[ROW($0)])
> LogicalFilter(condition=[=($0.TYPE, '')])
> LogicalProject(TYPE=[$0.TYPE])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
> {noformat}
> Plan before flatten:
> {noformat}
> LogicalProject(SKILL=[$0])
> LogicalFilter(condition=[=($0.TYPE, '')])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_SINGLE]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
