[
https://issues.apache.org/jira/browse/PHOENIX-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13890585#comment-13890585
]
ramkrishna.s.vasudevan commented on PHOENIX-10:
-----------------------------------------------
Some of my questions here
-> I can create a new expression called ArrayIndexPositionalExpression using a
linked hash set and set that to the ScanRegionObserver using attributes.(by
converting the contents in the linkedhashmap to a byte array). May be i would
persist those expressions itself.
bq.Post filter the List<KeyValue>
You mean in postScannerNext()? If so I would need to wrap the region scanner
in ScanRegionObserver with a new scanner and that should contain the
LinkedHashSet that is recreated back in the observer and the new wrapped
scanner would have a getter to get back this linkedhashset to be used in the
postScannerNext.
Doing so would mean that I have the result object with me and on that result
object we may have to identify the position of that value in the entire array
and rewrite the KV? But for doing that I may need to know the type of the array
here so that I would know how that array has been serialized.
I am trying to see how to relate this flow with KeyvalueSchema. Currently in a
normal select this does not come. Any reason for not doing this with filters
but with CPs?
> Push projection of a single ARRAY element to the server
> -------------------------------------------------------
>
> Key: PHOENIX-10
> URL: https://issues.apache.org/jira/browse/PHOENIX-10
> Project: Phoenix
> Issue Type: Improvement
> Reporter: James Taylor
> Assignee: ramkrishna.s.vasudevan
>
> If only a single array element is selected, we'll still return the entire
> array back to the client. Instead, we should push this to the server and only
> return the single array element. The same goes for the reference to an ARRAY
> in the WHERE clause. There's a general HBase fix for this (i.e. the ability
> to define a separate set of key values that will be returned versus key
> values available to filters) that has a patch here, but is deemed not
> possible to pull into the 0.94 branch by @lhofhansl.
> My thought is that we can add a Filter at the end our our filter chain that
> filters out any KeyValues that aren't in the SELECT expressions (i.e. filter
> out if a column is referenced in the WHERE clause, but not in the SELECT
> expressions). This same Filter could handle returning only the elements of
> the array that are referenced in the SELECT expression rather than the entire
> array.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
