[
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)
