[jira] [Updated] (PHOENIX-1251) Salted queries with range scan become full table scans

["James Taylor (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PHOENIX-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Taylor updated PHOENIX-1251:
----------------------------------
    Attachment: PHOENIX-1251_v4.patch

Unit tests passing, still working on end2end tests.

> 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
>         Attachments: PHOENIX-1251.patch, PHOENIX-1251_v2.patch, PHOENIX-1251_v3.patch, PHOENIX-1251_v4.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)