[
https://issues.apache.org/jira/browse/PHOENIX-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14122220#comment-14122220
]
James Taylor commented on PHOENIX-1211:
---------------------------------------
One more in navigate (the basic move-forward one):
{code}
} else { // We're in range, check the next slot
if (!slots.get(i).get(position[i]).isSingleKey() && i <
earliestRangeIndex) {
earliestRangeIndex = i;
}
// If we're past the last slot or we know we're seeking to the
next (in
// which case the previously updated slot was verified to be
within the
// range, so we don't need to check the rest of the slots. If
we were
// to check the rest of the slots, we'd get into trouble
because we may
// have a null byte that was incremented which screws up our
schema.next call)
if (i == nSlots-1 || seek) {
break;
}
i++; // TODO: use slotSpan here to increment
{code}
> 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)
