xiedeyantu commented on code in PR #4619: URL: https://github.com/apache/calcite/pull/4619#discussion_r2549290566
########## core/src/main/java/org/apache/calcite/rel/rules/MarkToSemiOrAntiJoinRule.java: ########## @@ -0,0 +1,139 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to you under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.calcite.rel.rules; + +import org.apache.calcite.plan.RelOptRuleCall; +import org.apache.calcite.plan.RelOptUtil; +import org.apache.calcite.plan.RelRule; +import org.apache.calcite.rel.RelNode; +import org.apache.calcite.rel.core.Filter; +import org.apache.calcite.rel.core.Join; +import org.apache.calcite.rel.core.JoinRelType; +import org.apache.calcite.rel.core.Project; +import org.apache.calcite.rex.RexCall; +import org.apache.calcite.rex.RexInputRef; +import org.apache.calcite.rex.RexNode; +import org.apache.calcite.sql.SqlKind; +import org.apache.calcite.tools.RelBuilder; +import org.apache.calcite.util.ImmutableBitSet; + +import org.immutables.value.Value; + +import java.util.ArrayList; +import java.util.List; + +import static org.apache.calcite.plan.RelOptUtil.conjunctions; + +/** + * Rule to simplify a mark join to semi join or anti join. + */ [email protected] +public class MarkToSemiOrAntiJoinRule + extends RelRule<MarkToSemiOrAntiJoinRule.Config> + implements TransformationRule { + + + /** Creates a MarkToSemiOrAntiJoinRule. */ + protected MarkToSemiOrAntiJoinRule(Config config) { + super(config); + } + + @Override public void onMatch(RelOptRuleCall call) { + final Project project = call.rel(0); + final Filter filter = call.rel(1); + final Join join = call.rel(2); + final RelBuilder builder = call.builder(); + + int markIndex = join.getRowType().getFieldCount() - 1; + ImmutableBitSet projectColumns = RelOptUtil.InputFinder.bits(project.getProjects(), null); + ImmutableBitSet filterColumns = RelOptUtil.InputFinder.bits(filter.getCondition()); + // Proj <- does not project marker + // Filter <- use marker in condition + // Join <- mark join + if (projectColumns.get(markIndex) || !filterColumns.get(markIndex)) { + return; + } + + // After decompose the filter condition by AND, there are only two cases to simplify: + // 1. only reference the marker, simplify to semi join + // 2. NOT(marker), and the join condition only contains IS [NOT] DISTINCT FROM, + // simplify to anti join + boolean toSemi = false; + boolean toAnti = false; + List<RexNode> filterConditions = RelOptUtil.conjunctions(filter.getCondition()); + List<RexNode> newFilterConditions = new ArrayList<>(); + for (RexNode condition : filterConditions) { + final ImmutableBitSet inputBits = RelOptUtil.InputFinder.bits(condition); + // marker not referenced + if (!inputBits.get(markIndex)) { + newFilterConditions.add(condition); + continue; + } + + // only marker referenced, to semi join + if (condition instanceof RexInputRef && !toAnti) { + toSemi = true; + continue; + } + // NOT(marker), and the join condition only contains IS [NOT] DISTINCT FROM, to anti join + if (condition instanceof RexCall + && condition.isA(SqlKind.NOT) + && ((RexCall) condition).getOperands().get(0) instanceof RexInputRef + && onlyContainsDistinctFrom(join.getCondition()) + && !toSemi) { + toAnti = true; + continue; + } + // other forms cannot be eliminated + return; + } + JoinRelType newJoinType = toSemi ? JoinRelType.SEMI : JoinRelType.ANTI; + RelNode result + = builder.push(join.getLeft()).push(join.getRight()) + .join(newJoinType, join.getCondition()) + .filter(newFilterConditions) + .project(project.getProjects()) + .build(); + call.transformTo(result); + } + + private static boolean onlyContainsDistinctFrom(RexNode condition) { + List<RexNode> conjunctions = conjunctions(condition); + for (RexNode expr : conjunctions) { + if (!expr.isA(SqlKind.IS_DISTINCT_FROM) && !expr.isA(SqlKind.IS_NOT_DISTINCT_FROM)) { + return false; + } + } + return true; + } + + /** Rule configuration. */ + @Value.Immutable + public interface Config extends RelRule.Config { + Config DEFAULT = ImmutableMarkToSemiOrAntiJoinRule.Config.of() + .withOperandSupplier(b1 -> + b1.operand(Project.class).oneInput(b2 -> + b2.operand(Filter.class).oneInput(b3 -> + b3.operand(Join.class).predicate(join -> join.getJoinType() == JoinRelType.MARK) Review Comment: > ```sql > select empno from emp where empno not in > (select empno from emp as emp_b where emp.ename = emp_b.ename); > ``` > > ``` > // new > LogicalProject(EMPNO=[$0]) > LogicalFilter(condition=[NOT($9)]) > LogicalJoin(condition=[AND(=($0, $9), IS NOT DISTINCT FROM($1, $10))], joinType=[mark]) > LogicalTableScan(table=[[CATALOG, SALES, EMP]]) > LogicalProject(EMPNO=[$0], ENAME0=[$10]) > LogicalJoin(condition=[=($10, $1)], joinType=[inner]) > LogicalTableScan(table=[[CATALOG, SALES, EMP_B]]) > LogicalAggregate(group=[{0}]) > LogicalProject(ENAME=[$1]) > LogicalTableScan(table=[[CATALOG, SALES, EMP]]) > ``` > > The plan above is the one generated by your implementation; however, the more concise plan is the one below. Could it be that this optimization was overlooked somewhere? > > ``` > Project [empno#27] > +- Join LeftAnti, (((empno#27 = empno#57) OR isnull((empno#27 = empno#57))) AND (ename#28 = ename#58)) > :- Project [empno#27, ename#28] > : +- Relation spark_catalog.default.emp[...] parquet > +- Project [empno#57, ename#58] > +- Relation spark_catalog.default.emp[...] parquet > ``` I feel that your line of thinking might be heading in the wrong direction. In my humble understanding, the purpose of decorrelation is to use a general algorithm to remove the correlation, not to obtain the optimal plan (or a certain desired form) directly from the decorrelation process. Currently, Calcite also has corresponding rules to convert queries into semi/anti joins, which feels like it could be a follow-up optimization item. I think for the first version, we should focus our energy on implementing the core algorithm into code. Perhaps you could file a JIRA ticket as an optimization item to be addressed after this PR. Otherwise, this PR might become too bloated and difficult to review. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
