[
https://issues.apache.org/jira/browse/TAJO-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14164625#comment-14164625
]
ASF GitHub Bot commented on TAJO-1107:
--------------------------------------
Github user babokim commented on a diff in the pull request:
https://github.com/apache/tajo/pull/193#discussion_r18624541
--- Diff:
tajo-core/src/main/java/org/apache/tajo/master/querymaster/Repartitioner.java
---
@@ -388,12 +392,35 @@ private static void
scheduleSymmetricRepartitionJoin(QueryMasterTask.QueryMaster
int joinTaskNum = Math.min(maxTaskNum, hashEntries.size());
LOG.info("The determined number of join tasks is " + joinTaskNum);
- FileFragment[] rightFragments = new FileFragment[1 +
(broadcastFragments == null ? 0 : broadcastFragments.length)];
- rightFragments[0] = fragments[1];
+ List<FileFragment> rightFragments = new ArrayList<FileFragment>();
+ rightFragments.add(fragments[1]);
+
if (broadcastFragments != null) {
- System.arraycopy(broadcastFragments, 0, rightFragments, 1,
broadcastFragments.length);
+ //In this phase a ScanNode has a single fragment.
+ //If there are more than one data files, that files should be added
to fragments or partition path
+ AbstractStorageManager storageManager = subQuery.getStorageManager();
+ int index = 0;
+ for (FileFragment eachFragment: broadcastFragments) {
--- End diff --
Ok, I'll replace broadcastFragments with broadcastScans before committing.
> Broadcast join on non-leaf node scans only first data file.
> -----------------------------------------------------------
>
> Key: TAJO-1107
> URL: https://issues.apache.org/jira/browse/TAJO-1107
> Project: Tajo
> Issue Type: Bug
> Reporter: Hyoungjun Kim
> Assignee: Hyoungjun Kim
> Priority: Minor
> Fix For: 0.9.0
>
>
> Fragments are determined by the Repartitioner. In the case of broadcast join
> Repartitioner uses different determine login according to node type(lead,
> non-leaf).
> Currently Tajo only uses first data file when broadcast join is non-leaf
> node. This is the cause of incorrect results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
