[
https://issues.apache.org/jira/browse/TAJO-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14353942#comment-14353942
]
ASF GitHub Bot commented on TAJO-1350:
--------------------------------------
Github user hyunsik commented on a diff in the pull request:
https://github.com/apache/tajo/pull/384#discussion_r26089560
--- Diff: tajo-plan/src/main/java/org/apache/tajo/plan/LogicalPlanner.java
---
@@ -1978,26 +1979,18 @@ public static boolean
checkIfBeEvaluatedAtJoin(QueryBlock block, EvalNode evalNo
return false;
}
- // When a 'case-when' is used with outer join, the case-when
expression must be evaluated
- // at the topmost join operator.
- // TODO - It's also valid that case-when is evalauted at the topmost
outer operator.
- // But, how can we know there is no further outer join operator
after this node?
- if (containsOuterJoin(block)) {
- if (!isTopMostJoin) {
- Collection<EvalNode> found =
EvalTreeUtil.findOuterJoinSensitiveEvals(evalNode);
- if (found.size() > 0) {
- return false;
- }
- }
+ /*
+ * For outer joins, only predicates which are specified at the on
clause can be evaluated during processing join.
+ * Other predicates from the where clause must be evaluated after the
join.
+ * The below code will be modified after improving join operators to
keep join filters by themselves (TAJO-1310).
+ */
+ if (PlannerUtil.isOuterJoin(node.getJoinType()) && !isOnPredicate) {
--- End diff --
Could explain your intension about this change? It would be great if I can
hear what the problem (or motivation) is and what your solution is.
> Refactor FilterPushDownRule::visitJoin() into well-defined, small methods
> -------------------------------------------------------------------------
>
> Key: TAJO-1350
> URL: https://issues.apache.org/jira/browse/TAJO-1350
> Project: Tajo
> Issue Type: Improvement
> Components: planner/optimizer
> Reporter: Hyunsik Choi
> Assignee: Jihoon Son
> Fix For: 0.11
>
> Attachments: TAJO-1350.patch
>
>
> FilterPushDownRule::visitJoin() is too long and complicated. It handles
> various cases in a single method. We need to refactor this method into
> several small and well-defined methods.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
