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

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

Github user hyunsik commented on the pull request:

    https://github.com/apache/tajo/pull/381#issuecomment-74443711
  
    The patch looks good to me. The changes clean up join operators and and 
join plans. This separation between join filter and join condition would make 
more opportunities to clean up other join related codes later. I leave some 
comments. After your answer, I'll finish the review.
    
    In addition, I think that FilterPushDownRule::visitJoin has a long single 
method. We need to clean up and refactor the method into several small 
well-defined methods. For it, we may need another jira.


> 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