danny0405 commented on a change in pull request #1157: [CALCITE-2969] Improve
design of join-like relational expressions
URL: https://github.com/apache/calcite/pull/1157#discussion_r279149741
##########
File path:
core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableJoinRule.java
##########
@@ -71,26 +71,25 @@
EnumerableRules.LOGGER.debug(e.toString());
return null;
}
+ } else {
+ RelNode newRel;
+ try {
+ newRel = EnumerableHashJoin.create(
+ left,
+ right,
+ info.getEquiCondition(left, right, cluster.getRexBuilder()),
+ join.getVariablesSet(),
+ join.getJoinType());
+ } catch (InvalidRelException e) {
+ EnumerableRules.LOGGER.debug(e.toString());
+ return null;
+ }
+ if (!info.isEqui()) {
+ newRel = new EnumerableFilter(cluster, newRel.getTraitSet(),
+ newRel, info.getRemaining(cluster.getRexBuilder()));
+ }
Review comment:
For the current implementation, the SemiJoin's join info is definitely equi,
so it is okey to not shift the join keys, actually if the join only outputs
oneside, we could not even add a filter here if the filter keys comes from the
non-output side.
We can merge the EquiJoinInfo and NonEquiJoinInfo into JoinInfo, but this
has non relationship with code snippet here. Actually for the first commit i
merged them, but seems not that point.
I agree that we should add a check here for adding filer, although the
current implementation can guarantee this.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
