[
https://issues.apache.org/jira/browse/PHOENIX-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15341224#comment-15341224
]
James Taylor commented on PHOENIX-3012:
---------------------------------------
isReverse is true when {{plan.getOrderBy() == OrderBy.REV_ROW_KEY_ORDER_BY}}.
So only when the order by was optimized out as a reverse scan.
Also, the other bug you found, I think it might be when it's order preserving
and we're using GroupedByRegionObserver.scanOrdered(), we still return the rows
with the salt byte here:
{code}
if (currentKey != null) {
byte[] value = aggregators.toBytes(rowAggregators);
KeyValue keyValue =
KeyValueUtil.newKeyValue(currentKey.get(),
currentKey.getOffset(),
currentKey.getLength(), SINGLE_COLUMN_FAMILY,
SINGLE_COLUMN,
AGG_TIMESTAMP, value, 0, value.length);
{code}
I think we should add {{SaltingUtil.NUM_SALTING_BYTES}} to the
currentKey.getOffset() and subtract it from the length to not have the salt
byte there. Just a guess.
> DistinctPrefixFilter logic fails with local indexes and salted tables
> ---------------------------------------------------------------------
>
> Key: PHOENIX-3012
> URL: https://issues.apache.org/jira/browse/PHOENIX-3012
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Lars Hofhansl
> Priority: Critical
> Fix For: 4.8.0
>
> Attachments: 3012-does.not.work.txt
>
>
> Arrghhh... Another case where there are issues.
> With local indexes parents (PHOENIX-258) does not work.
> I do not understand enough about local indexes to say why offhand, only that
> it appears to be broken.
> I'll look.Might be best to turn this off for local indexes for now (if that's
> easy to detect) while I figure this out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
