[
https://issues.apache.org/jira/browse/PHOENIX-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410785#comment-15410785
]
Hadoop QA commented on PHOENIX-3152:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12822453/PHOENIX-3152.patch
against master branch at commit 67b8b73630676b2f75ff05eed194faf9b7e856ca.
ATTACHMENT ID: 12822453
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
34 warning messages.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/498//testReport/
Javadoc warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/498//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/498//console
This message is automatically generated.
> Incorrect comparator in QueryOptimizer may cause IllegalArgumentException
> -------------------------------------------------------------------------
>
> Key: PHOENIX-3152
> URL: https://issues.apache.org/jira/browse/PHOENIX-3152
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.8.0
> Reporter: Sergey Soldatov
> Attachments: PHOENIX-3152.patch, PHOENIX-3152.sql
>
>
> The problem code is in QueryOptimizer#orderPlansBestToWorst
> When we have a lot of local similar indexes, all of them comes to the array
> of best candidates. After that we try to sort them using our own Comparator.
> In the compare we check first:
> 1. bound pk columns count
> 2. groupBy order
> 3. number of columns
> for two local indexes on different columns first 3 steps always passed (since
> they are equal)
> And now we execute the following checks:
> {noformat}
> // If all things are equal, don't choose local index as it
> forces scan
> // on every region (unless there's no start/stop key)
> if (table1.getIndexType() == IndexType.LOCAL) {
> return
> plan1.getContext().getScanRanges().getRanges().isEmpty() ? -1 : 1;
> }
> if (table2.getIndexType() == IndexType.LOCAL) {
> return
> plan2.getContext().getScanRanges().getRanges().isEmpty() ? 1 : -1;
> }
> {noformat}
> obvious that for similar two plans with similar scan ranges {{compare
> (plan1, plan2)}} and {{compare(plan2, plan1)}} will return the same result (1
> if ranges are not empty, -1 otherwise). This may cause following exception
> from {{Collections.sort}} :
> {noformat}
> at java.util.TimSort.mergeLo(TimSort.java:777)
> at java.util.TimSort.mergeAt(TimSort.java:514)Listening for transport
> at java.util.TimSort.mergeCollapse(TimSort.java:441)
> at java.util.TimSort.sort(TimSort.java:245)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:175)
> {noformat}
> I would suggest to add a check that if both plans are local indexes, then
> consider them equal, otherwise execute the check. [~jamestaylor],
> [~ram_krish] any thoughts?
> [[email protected]] FYI
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
