[
https://issues.apache.org/jira/browse/PHOENIX-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14123185#comment-14123185
]
Kyle Buzsaki commented on PHOENIX-1211:
---------------------------------------
In making these modifications, I'm having a hard time understanding why we're
incrementing these index variables more depending on the slotSpan. i and j are
used to index into the position array. Doesn't incrementing them by certain
values all the time mean that we completely ignore certain indices of the
position array?
For example, if we have 4 slots with the following slot span and position array
(the two should always be the same size, shouldn't they?)
{code}
slotSpan: | 0 | 0 | 1 | 0 |
position: | 0 | 0 | 0 | 0 |
{code}
If i = 2 and we perform the following incrment:
{code}
i += slotSpan[i] + 1;
{code}
then i is now 4, which is out of bounds of the position array. On top of that,
we've completely skipped past index 3, and it seems like we'll never use it.
> Use skip scan when row value constructor uses leading row key columns
> ----------------------------------------------------------------------
>
> Key: PHOENIX-1211
> URL: https://issues.apache.org/jira/browse/PHOENIX-1211
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Kyle Buzsaki
> Attachments: PHOENIX-1211-diff.patch
>
>
> We currently only use a skip scan for a row value constructor equality or in
> list expression is fully qualified. We can fairly easily use it when only
> some of the leading pk columns are used.
> For example:
> {code}
> WHERE (a,b) IN ((1,2),(3,4))
> {code}
> If the PK is (a,b,c), we can still use a skip scan. We need to pass through
> the slotSpan array in this case too, to the SkipScanFilter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
