[
https://issues.apache.org/jira/browse/TAJO-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14317754#comment-14317754
]
ASF GitHub Bot commented on TAJO-1310:
--------------------------------------
Github user jihoonson commented on a diff in the pull request:
https://github.com/apache/tajo/pull/381#discussion_r24563379
--- Diff:
tajo-core/src/main/java/org/apache/tajo/engine/planner/physical/HashLeftOuterJoinExec.java
---
@@ -211,12 +169,16 @@ protected void loadRightToHashTable() throws
IOException {
}
List<Tuple> newValue = tupleSlots.get(keyTuple);
- if (newValue != null) {
- newValue.add(tuple);
- } else {
- newValue = new ArrayList<Tuple>();
- newValue.add(tuple);
- tupleSlots.put(keyTuple, newValue);
+ try {
+ if (newValue != null) {
+ newValue.add(tuple.clone());
--- End diff --
This problem is quite complicated. So, I create a new issue
(https://issues.apache.org/jira/browse/TAJO-1343) to handle this problem.
Please review the patch.
> Maintaining join filters in join operators
> ------------------------------------------
>
> Key: TAJO-1310
> URL: https://issues.apache.org/jira/browse/TAJO-1310
> Project: Tajo
> Issue Type: Improvement
> Components: parser, physical operator, planner/optimizer
> Reporter: Jihoon Son
> Assignee: Jihoon Son
> Priority: Blocker
> Fix For: 0.11
>
>
> *Introduction*
> A join statement can contain join predicates and join filters.
> Join predicates are evaluated during performing the join operation, while
> join filters are evaluated on the set of join results.
> Let me consider an example join query as follows:
> {noformat}
> default> select n_nationkey from nation left outer join region on n_nationkey
> = r_regionkey where r_regionkey is null;
> {noformat}
> In this query, the join predicates and filters are as follows:
> * Join predicates: n_nationkey = r_regionkey
> * Join filters: r_regionkey is null
> *Problem*
> Currently, in query plans, join filters are handled as selection operators,
> while join predicates are maintained as member variables of join operators.
> This approach makes the implementation simple, but difficult to find the
> selection operators corresponding to join operators because they are
> separately maintained.
> This problem is critical when the logical plan optimizer optimizes the join
> order of a query statement that contains two or more joins each of that has
> join filters.
> *Solution*
> Join filters should be distinguished from selection filters, and maintained
> in the corresponding join operators. For this, we should add join filtlers to
> the join expression, the logical join node, and several physical join
> executors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
