[
https://issues.apache.org/jira/browse/CALCITE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396297#comment-16396297
]
Vitalii Diravka commented on CALCITE-2205:
------------------------------------------
Looks like inferred predicates are correct and CALCITE-1995 fix works good.
What about such test case (new filter is created for filter relNode with the
same condidtion):
{code}
@Test public void testSameFilter() {
// Equivalent SQL:
// SELECT *
// FROM emp
// WHERE deptno = 20
final RelBuilder builder = RelBuilder.create(config().build());
RelNode root =
builder.scan("EMP")
.filter(
builder.equals(builder.field("DEPTNO"), builder.literal(20)))
.build();
System.out.println(RelOptUtil.toString(root,
SqlExplainLevel.ALL_ATTRIBUTES));
assertThat(str(root),
is("LogicalFilter(condition=[=($7, 20)])\n"
+ " LogicalTableScan(table=[[scott, EMP]])\n"));
RelNode newRoot = builder.push(root)
.filter(
builder.equals(builder.field("DEPTNO"), builder.literal(20)))
.build();
System.out.println(RelOptUtil.toString(newRoot,
SqlExplainLevel.ALL_ATTRIBUTES));
assertThat(str(newRoot),
is("LogicalFilter(condition=[=($7, 20)])\n"
+ " LogicalTableScan(table=[[scott, EMP]])\n"));
}
{code}
Output:
{code}
LogicalFilter(condition=[=($7, 20)]): rowcount = 2.1, cumulative cost = {16.1
rows, 29.0 cpu, 0.0 io}, id = 1
LogicalTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost =
{14.0 rows, 15.0 cpu, 0.0 io}, id = 0
LogicalFilter(condition=[=($7, 20)]): rowcount = 2.1, cumulative cost =
{18.200000000000003 rows, 31.1 cpu, 0.0 io}, id = 2
LogicalFilter(condition=[=($7, 20)]): rowcount = 2.1, cumulative cost = {16.1
rows, 29.0 cpu, 0.0 io}, id = 1
LogicalTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost =
{14.0 rows, 15.0 cpu, 0.0 io}, id = 0
java.lang.AssertionError:
Expected: is "LogicalFilter(condition=[=($7, 20)])\n
LogicalTableScan(table=[[scott, EMP]])\n"
but: was "LogicalFilter(condition=[=($7, 20)])\n
LogicalFilter(condition=[=($7, 20)])\n LogicalTableScan(table=[[scott,
EMP]])\n" <Click to see difference>
{code}
It actually fails on current master. Resolving this doesn't resolve current
Jira issue, but I hope it should be improved.
Current Jira issue is connected to creating the same filter for HepRelVertex
relNode. I believe it should be resolved in HepPlanner#applyRule method scope.
> One more Infinite loop for JoinPushTransitivePredicatesRule
> -----------------------------------------------------------
>
> Key: CALCITE-2205
> URL: https://issues.apache.org/jira/browse/CALCITE-2205
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.15.0
> Reporter: Vitalii Diravka
> Assignee: Julian Hyde
> Priority: Major
> Fix For: 1.16.0
>
>
> CALCITE-2200 resolves some cases of infinite loop via stopping of recursion
> in HepPlanner#applyRules, when newVertex is the same as vertex.
> In this jira one more case of infinite loop is described:
> JoinPushTransitivePredicatesRule#onMatch generates new right or left inputs
> via using RelBuilder#filter method on top of LogicalFilter RelNode with the
> same condition.
> In this case a new RelNode shouldn't be created. Possible fix to change logic
> of RelBuilder#filter method.
> TestCase for reproduce:
> {code}
> @Test public void testJoinPushTransitivePredicatesRule2() {
> HepProgramBuilder builder = new HepProgramBuilder();
> builder.addRuleInstance(JoinPushTransitivePredicatesRule.INSTANCE);
> HepProgram build = builder.build();
> HepPlanner hepPlanner = new HepPlanner(build);
> final String sql = "select n1.SAL from EMPNULLABLES_20 n1 where n1.SAL\n"
> + "IN (select n2.SAL from EMPNULLABLES_20 n2 "
> + "where n1.SAL = n2.SAL or n1.SAL = 4)";
> sql(sql)
> .withDecorrelation(true)
> .with(hepPlanner)
> .check();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
