[ 
https://issues.apache.org/jira/browse/TAJO-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14322204#comment-14322204
 ] 

ASF GitHub Bot commented on TAJO-1310:
--------------------------------------

Github user hyunsik commented on a diff in the pull request:

    https://github.com/apache/tajo/pull/381#discussion_r24726468
  
    --- Diff: 
tajo-core/src/main/java/org/apache/tajo/engine/planner/physical/BNLJoinExec.java
 ---
    @@ -190,15 +152,12 @@ public Tuple next() throws IOException {
             }
           }
     
    -      frameTuple.set(leftTuple, rightIterator.next());
    -      if (hasJoinQual) {
    -        if (joinQual.eval(inSchema, frameTuple).isTrue()) {
    -          projector.eval(frameTuple, outputTuple);
    -          return outputTuple;
    +      updateFrameTuple(leftTuple, rightIterator.next());
    +
    +      if (evalQual()) {
    --- End diff --
    
    Except for BNLJoinExec, all join operators (hash, and merge joins) must 
have join conditions.
    
    BNLJoinExec can be used for cross join, meaning that there is no join 
condition. Nevertheless, it can have join filter as follows:
    
    ```
    SELECT x, y, z FROM A, B WHERE concat (x,y) = 'keyword'
    ```
    
    ```concat (x,y) = 'keyword'``` will be play a join filter in BNL join 
operator. So, we need to consider join condition and filter separately in 
BNLJoinExec.


> 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.10
>
>
> *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)

Reply via email to