[ https://issues.apache.org/jira/browse/FLINK-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631793#comment-14631793 ]
ASF GitHub Bot commented on FLINK-2105: --------------------------------------- Github user fhueske commented on the pull request: https://github.com/apache/flink/pull/907#issuecomment-122389145 +1 for @chiwanpark's first point I was actually also thinking about separating different join types for performance. What could also help is to make the `outerJoinType` variable `final`. That might help the JIT compiler. Since separating the classes would mean 9 classes instead of 3, I would suggest to implement a micro-benchmark (only for one of the three types) to check the performance implications. > Implement Sort-Merge Outer Join algorithm > ----------------------------------------- > > Key: FLINK-2105 > URL: https://issues.apache.org/jira/browse/FLINK-2105 > Project: Flink > Issue Type: Sub-task > Components: Local Runtime > Reporter: Fabian Hueske > Assignee: Ricky Pogalz > Priority: Minor > Fix For: pre-apache > > > Flink does not natively support outer joins at the moment. > This issue proposes to implement a sort-merge outer join algorithm that can > cover left, right, and full outer joins. > The implementation can be based on the regular sort-merge join iterator > ({{ReusingMergeMatchIterator}} and {{NonReusingMergeMatchIterator}}, see also > {{MatchDriver}} class) > The Reusing and NonReusing variants differ in whether object instances are > reused or new objects are created. I would start with the NonReusing variant > which is safer from a user's point of view and should also be easier to > implement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)