[jira] [Commented] (PHOENIX-3157) Refactor DistinctPrefixFilter as filter wrapper so that it can work with non-pk column filters.

["Lars Hofhansl (JIRA)" <ji...@apache.org>]

    [ 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)