[jira] [Updated] (CALCITE-3975) ProjectFilterTransposeRule should succeed for project that happens to reference all input columns
[
https://issues.apache.org/jira/browse/CALCITE-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3975:
-
Affects Version/s: 1.22.0
> ProjectFilterTransposeRule should succeed for project that happens to
> reference all input columns
> -
>
> Key: CALCITE-3975
> URL: https://issues.apache.org/jira/browse/CALCITE-3975
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.22.0
>Reporter: Steven Talbot
>Assignee: Julian Hyde
>Priority: Major
>
> ... that is, I think
> If I make the trivial fix of just "only skip trivial projects", something
> like
> {noformat}
> && origProj.getProjects().stream().allMatch((proj) -> proj instanceof
> RexInputRef) {noformat}
> at
> [https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/PushProjector.java#L354
>
> |https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/PushProjector.java#L354]HepPlanner
> goes into infinite recursion with the rule.
> But here's the test case:
>
> {code:java}
> @Test public void testPushProjectPastFilter3() {
> final String sql = "select empno + deptno, ename, job, mgr, hiredate, sal,
> comm, slacker from emp where sal = 10 * comm\n"
> + "and upper(ename) = 'FOO'";
> sql(sql).withRule(ProjectFilterTransposeRule.INSTANCE).check();
> }
> {code}
>
>
>
> {noformat}
>
>
>
>
>
>
>
>
>
>
> {noformat}
>
> There's no reason the rule shouldn't succeed here, right? Or am I missing
> something?
> The reason this rule goes into an infinite recursion with hepplanner is
> because it sticks a project on top after transpose to handle common
> expressions extracted from the filter and the project. Ideally, it could have
> a mode where it could avoid doing that and do a true "transpose" if there was
> no need for it. For example, I don't think there is a a need for a reproject
> on top in this test case: you can just transpose and everything works as it
> should. This would be another way to avoid infinite recursion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3975) ProjectFilterTransposeRule should succeed for project that happens to reference all input columns
[
https://issues.apache.org/jira/browse/CALCITE-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Talbot updated CALCITE-3975:
---
Description:
... that is, I think
If I make the trivial fix of just "only skip trivial projects", something like
{noformat}
&& origProj.getProjects().stream().allMatch((proj) -> proj instanceof
RexInputRef) {noformat}
at
[https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/PushProjector.java#L354
|https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/PushProjector.java#L354]HepPlanner
goes into infinite recursion with the rule.
But here's the test case:
{code:java}
@Test public void testPushProjectPastFilter3() {
final String sql = "select empno + deptno, ename, job, mgr, hiredate, sal,
comm, slacker from emp where sal = 10 * comm\n"
+ "and upper(ename) = 'FOO'";
sql(sql).withRule(ProjectFilterTransposeRule.INSTANCE).check();
}
{code}
{noformat}
{noformat}
There's no reason the rule shouldn't succeed here, right? Or am I missing
something?
The reason this rule goes into an infinite recursion with hepplanner is because
it sticks a project on top after transpose to handle common expressions
extracted from the filter and the project. Ideally, it could have a mode where
it could avoid doing that and do a true "transpose" if there was no need for
it. For example, I don't think there is a a need for a reproject on top in this
test case: you can just transpose and everything works as it should. This would
be another way to avoid infinite recursion.
was:
... that is, I think
If I make the trivial fix of just "only skip trivial projects", something like
{noformat}
&& origProj.getProjects().stream().allMatch((proj) -> proj instanceof
RexInputRef) {noformat}
at
[https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/PushProjector.java#L354
|https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/PushProjector.java#L354]HepPlanner
goes into infinite recursion with the rule.
But here's the test case:
{code:java}
@Test public void testPushProjectPastFilter3() {
final String sql = "select empno + deptno, ename, job, mgr, hiredate, sal,
comm, slacker from emp where sal = 10 * comm\n"
+ "and upper(ename) = 'FOO'";
sql(sql).withRule(ProjectFilterTransposeRule.INSTANCE).check();
}
{code}
{noformat}
{noformat}
There's no reason the rule shouldn't fire here, right? Or am I missing
something?
The reason this rule goes into an infinite recursion with hepplanner is because
it sticks a project on top after transpose to handle common expressions
extracted from the filter and the project. Ideally, it could have a mode where
it could avoid doing that and do a true "transpose" if there was no need for
it. For example, I don't think there is a a need for a reproject on top in this
test case: you can just transpose and everything works as it should. This would
be another way to avoid infinite recursion.
> ProjectFilterTransposeRule should succeed for project that happens to
> reference all input columns
> -
>
> Key: CALCITE-3975
> URL: https://issues.apache.org/jira/browse/CALCITE-3975
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Priority: Major
>
> ... that is, I think
> If I make the trivial fix of just "only skip trivial projects", something
> like
> {noformat}
> && origProj.getProjects().stream().allMatch((proj) -> proj instanceof
> RexInputRef) {noformat}
> at
> [https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/PushProjector.java#L354
>
> |https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/PushProjector.java#L354]HepPlanner
> goes into infinite recursion with the rule.
> But here's the test case:
>
> {code:java}
> @Test public void testPushProjectPastFilter3() {
> final String sql = "select empno + deptno, ename, job, mgr, hiredate, sal,
> comm, slacker from emp where sal = 10 * comm\n"
> + "and upper(ename) = 'FOO'";
> sql(sql).withRule(ProjectFilterTransposeRule.INSTANCE).check();
> }
> {code}
>
>
>
> {noformat}
>
>
>
>
>
>
>
[jira] [Updated] (CALCITE-3975) ProjectFilterTransposeRule should succeed for project that happens to reference all input columns
[
https://issues.apache.org/jira/browse/CALCITE-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Talbot updated CALCITE-3975:
---
Summary: ProjectFilterTransposeRule should succeed for project that happens
to reference all input columns (was: ProjectFilterTransposeRule should fire
for project that happens to reference all input columns)
> ProjectFilterTransposeRule should succeed for project that happens to
> reference all input columns
> -
>
> Key: CALCITE-3975
> URL: https://issues.apache.org/jira/browse/CALCITE-3975
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Priority: Major
>
> ... that is, I think
> If I make the trivial fix of just "only skip trivial projects", something
> like
> {noformat}
> && origProj.getProjects().stream().allMatch((proj) -> proj instanceof
> RexInputRef) {noformat}
> at
> [https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/PushProjector.java#L354
>
> |https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/PushProjector.java#L354]HepPlanner
> goes into infinite recursion with the rule.
> But here's the test case:
>
> {code:java}
> @Test public void testPushProjectPastFilter3() {
> final String sql = "select empno + deptno, ename, job, mgr, hiredate, sal,
> comm, slacker from emp where sal = 10 * comm\n"
> + "and upper(ename) = 'FOO'";
> sql(sql).withRule(ProjectFilterTransposeRule.INSTANCE).check();
> }
> {code}
>
>
>
> {noformat}
>
>
>
>
>
>
>
>
>
>
> {noformat}
>
> There's no reason the rule shouldn't fire here, right? Or am I missing
> something?
> The reason this rule goes into an infinite recursion with hepplanner is
> because it sticks a project on top after transpose to handle common
> expressions extracted from the filter and the project. Ideally, it could have
> a mode where it could avoid doing that and do a true "transpose" if there was
> no need for it. For example, I don't think there is a a need for a reproject
> on top in this test case: you can just transpose and everything works as it
> should. This would be another way to avoid infinite recursion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
