[
https://issues.apache.org/jira/browse/PHOENIX-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15429596#comment-15429596
]
Lars Hofhansl commented on PHOENIX-3157:
----------------------------------------
The DistinctPrefixFilter would wrap its inner Filter and override
filterKeyValue and filterRow.
If the inner filterKeyValue returns at least one code to include a Cell
*and*the inner filterRow returns false, then call to filterKeyValue could skip
on last seen row key - which it would need to keep track of.
It's not intellectually hard, but the details will be tricky.
> Refactor DistinctPrefixFilter as filter wrapper so that it can work with
> non-pk column filters.
> -----------------------------------------------------------------------------------------------
>
> Key: PHOENIX-3157
> URL: https://issues.apache.org/jira/browse/PHOENIX-3157
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Lars Hofhansl
> Fix For: 4.9.0
>
>
> See PHOENIX-3156. The issue is pretty tricky:
> # only filterKeyValue can make skip decision
> # we're skiping rows (not Cells)
> # the next Cell we skip to is dynamic (not know ahead of time)
> # we can only skip if the row as a whole has not been filtered
> So in order to support non-pk column filters with this optimization (i.e.
> SELECT DISTINCT(pk1-prefix) FROM table WHERE non-pk-column = xxx) we need to
> refashion this is FilterWrapper and only fire the optimization when the inner
> filter did not filter the entire row, this is in many cases hard to
> determine. It's certainly more complex than the TransactionVisibilityFilter.
> [~giacomotaylor]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
