I don't think you answered my main question: are you referring to the RelNode's row type or the RelRoot validated row type? Before I try to review the specific tests I think it is important to be clear what we are talking about.
Some rules maintain the column names in a relnode's row type, others do not. When I say semantically meaningless I'm saying that Relnode rowtype field names have no meaning in a plan. Take a plan, replace all the row types on relnodes with rowtypes that have the same data types but randomized field names and the plan meaning doesn't change (in Calcite's eyes). Note, I've seen many systems that use Calcite which rely on RelNode rowtypes. This is a latent bug in those systems. I have seen occasions where rowtype equality (including fieldnames) is used in rule decisions and that some rules may behave differently depending on column names. However, I see that as a weakness of support in those specific rules (since the names are arbitrary). On Thu, Nov 25, 2021 at 1:53 AM Yanjing Wang <[email protected]> wrote: > I think the "The names of the fields in RelNodes are semantically > meaningless in Calcite's eyes" may not always be applicable. > If I change the testUnionMergeRule test case to the following(just change > the final output *** to *name as ename, deptno as edeptno*): > @Test void testUnionMergeRule() { > final String sql = "select name as ename, deptno as edeptno from (\n" > + "select * from (\n" > + " select name, deptno from dept\n" > + " union all\n" > + " select name, deptno from\n" > + " (\n" > + " select name, deptno, count(1) from dept group by name, > deptno\n" > + " union all\n" > + " select name, deptno, count(1) from dept group by name, > deptno\n" > + " ) subq\n" > + ") a\n" > + "union all\n" > + "select name, deptno from dept\n" > + ") aa\n"; > sql(sql) > .withRule(CoreRules.PROJECT_SET_OP_TRANSPOSE, > CoreRules.PROJECT_REMOVE, > CoreRules.UNION_MERGE) > .check(); > } > > The result plan is equal to the unchanged one, But they shouldn't be equal > because I modified the final output column alias. > However, the plan before optimization is correct. > > > > Jacques Nadeau <[email protected]> 于2021年11月25日周四 上午11:50写道： > > > Are you looking at the RelRoot's field names or the field names of the > > RelNodes in the plan? The names of the fields in RelNodes are > semantically > > meaningless in Calcite's eyes (rule semantics are based on ordinal > > position, not field name). The validated row type (and correct field > names) > > may only exist in the RelRoot.validatedRowType. Sometimes the RelNode of > > the output of the plan matches this RowType but often it does not. > > > > On Tue, Nov 23, 2021 at 10:47 PM Yanjing Wang <[email protected] > > > > wrote: > > > > > Hi, team > > > I'm using ProjectRemoveRule to simplify my logical plan, But the plan > > > sometimes miss its project alias, I find the rule hasn't checked the > > alias > > > for project row type identity equation, so I think it may be a bug, I > > have > > > tried to reproduce the problem, but I failed to build two projects. > > > > > > I have tried the following but the plan always ignores the alias: > > > > > > final Function<RelBuilder, RelNode> relFn = b -> { > > > RelNode plan = b.scan("EMP") > > > .project( > > > b.field("DEPTNO"), > > > b.field("ENAME") > > > ) > > > .project( > > > b.alias(b.field(0), "DEPTNO_ALIAS"), > > > b.alias(b.field(1), "ENAME_ALIAS") > > > ) > > > .build(); > > > return plan; > > > }; > > > > > > relFn(relFn) > > > .withRule( > > > CoreRules.PROJECT_REMOVE) > > > .withRelBuilderConfig(b -> b.withBloat(-1)) > > > .check(); > > > > > > > > > So I resort to modifying existing test case to reproduce, I change > > > the testUnionMergeRule test case in RelOptRulesTest.java. I change its > > > final projection *** to *name as ename, deptno as edeptno*, > > > and the plan miss the alias again. I think the hep rules shouldn't > remove > > > the alias which are output column label. > > > > > >
