[
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_v6.patch
WIP. Just a few straggling test failures.
> 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, PHOENIX-1251_v5.patch,
> PHOENIX-1251_v6.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)
