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

Hudson commented on PHOENIX-1251:
---------------------------------

SUCCESS: Integrated in Phoenix | 4.0 | Hadoop2 #195 (See 
[https://builds.apache.org/job/Phoenix-4.0-hadoop2/195/])
PHOENIX-1251 Salted queries with range scan become full table scans (jtaylor: 
rev 2d0aeacff5b38805df85f7be5731eb608abc3f4c)
* phoenix-core/src/main/java/org/apache/phoenix/filter/SkipScanFilter.java
* phoenix-core/src/main/java/org/apache/phoenix/compile/ScanRanges.java


> Salted queries with range scan become full table scans
> ------------------------------------------------------
>
>                 Key: PHOENIX-1251
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1251
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Kyle Buzsaki
>            Assignee: James Taylor
>             Fix For: 5.0.0, 4.2, 3.2
>
>         Attachments: PHOENIX-1251.patch, PHOENIX-1251_v2.patch, 
> PHOENIX-1251_v3.patch, PHOENIX-1251_v4.patch, PHOENIX-1251_v5.patch, 
> PHOENIX-1251_v6.patch, PHOENIX-1251_v7.patch, PHOENIX-1251_v8a.patch, 
> PHOENIX-1251_v8b.patch, PHOENIX-1251_v9.patch
>
>
> See InListIT#testLeadingPKWithTrailingRVCSlotHole as an example query that 
> will fail when given the /*+ RANGE_SCAN */ hint.
> The issue is caused by the WhereOptimizer extracting the leading partially 
> qualified row keys of the where clause but improperly producing splitScan 
> start and stop rows in parallel iterators. 
> For example, with a where clause like:
> {code}
> SELECT * FROM TABLE_SALTED_4 WHERE pk1 = 2 and pk3 = 4;
> {code}
> The ScanRanges will set the scan boundaries as:
> {code}
> [\x00\x80\x00\x00\x02 - \x03\x80\x00\x00\x03]
> {code}
> This is technically correct as the scan start/stop rows need to include the 
> salt byte, but it means that naively intersecting the scan ranges with region 
> boundaries such as:
> {code}
> [* - \x01]
> [\x01 - \x02]
> [\x02 - \x03]
> [\x03 - *]
> {code}
> Will produce the following partially incorrect splitScan boundaries:
> {code}
> [\x00\x80\x00\x00\x02  - \x01]
> [\x01 - \x02]
> [\x02 - \x03]
> [\x03 - \x03\x80\x00\x00\x03]
> {code}
> Note that this is only a problem when the /*+ RANGE_SCAN */ hint is given. 
> Without a hint, this query will use a skip scan, sidestepping the issue.
> This is also related to PHOENIX-1163 and depending on how PHOENIX-1163 is 
> resolved, could be fixed at the same time.



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

Reply via email to