[
https://issues.apache.org/jira/browse/MAPREDUCE-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749082#action_12749082
]
Hadoop QA commented on MAPREDUCE-885:
-------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12418034/MAPREDUCE-885.5.patch
against trunk revision 808730.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 4 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
-1 findbugs. The patch appears to introduce 3 new Findbugs warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
-1 core tests. The patch failed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-vesta.apache.org/536/testReport/
Findbugs warnings:
http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-vesta.apache.org/536/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results:
http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-vesta.apache.org/536/artifact/trunk/build/test/checkstyle-errors.html
Console output:
http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-vesta.apache.org/536/console
This message is automatically generated.
> More efficient SQL queries for DBInputFormat
> --------------------------------------------
>
> Key: MAPREDUCE-885
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-885
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Aaron Kimball
> Assignee: Aaron Kimball
> Attachments: MAPREDUCE-885.2.patch, MAPREDUCE-885.3.patch,
> MAPREDUCE-885.4.patch, MAPREDUCE-885.5.patch, MAPREDUCE-885.patch
>
>
> DBInputFormat generates InputSplits by counting the available rows in a
> table, and selecting subsections of the table via the "LIMIT" and "OFFSET"
> SQL keywords. These are only meaningful in an ordered context, so the query
> also includes an "ORDER BY" clause on an index column. The resulting queries
> are often inefficient and require full table scans. Actually using multiple
> mappers with these queries can lead to O(n^2) behavior in the database, where
> n is the number of splits. Attempting to use parallelism with these queries
> is counter-productive.
> A better mechanism is to organize splits based on data values themselves,
> which can be performed in the WHERE clause, allowing for index range scans of
> tables, and can better exploit parallelism in the database.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
