[jira] [Updated] (PHOENIX-1251) Salted queries with partially qualified row keys fail with the /*+ RANGE_SCAN */ hint

["Kyle Buzsaki (JIRA)" <ji...@apache.org>]

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

Kyle Buzsaki updated PHOENIX-1251:
----------------------------------
    Description: 
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.

  was:
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}


> Salted queries with partially qualified row keys fail with the /*+ RANGE_SCAN */ hint
> -------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-1251
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1251
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Kyle Buzsaki
>
> 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)