phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-3152) Incorrect comparator in QueryOptimizer may cause IllegalArgumentException
Date Sun, 07 Aug 2016 02:40:20 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410802#comment-15410802
] 

James Taylor commented on PHOENIX-3152:
---------------------------------------

+1 for the patch.  Let's get this into the new RC too, so please commit to 4.8 and 4.x branches.

> 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?
> [~ankit@apache.org] FYI



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message