[
https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110918#comment-14110918
]
Maryann Xue commented on PHOENIX-852:
-------------------------------------
bq. One other question. In HashCacheClient, can you remind me what this does
(maybe add a comment?):
Ok, will do. This is to evaluate the value set for InExpression in the same
iteration where we do hash-table building.
bq. And instead of the code below, it'd be better if you called into
WhereOptimizer to get this information. There are cases beyond a simple column
reference that we'd be able to optimize (like a SUBSTR(rowKeyCol, 1, 3), or
even a row value constructor construct):
The reason why I do that now is to sort the join keys in a fashion to organize
them into a RowValueConstructor with as many leading key parts as possible. for
example, c1 is the first join key and c0 is second, that way we'll be able to
get a (c0,c1) for the final dynamic filter. Yeah, I also understand there are
situations you mentioned above. So any way we can cover these both situations
best?
> Optimize child/parent foreign key joins
> ---------------------------------------
>
> Key: PHOENIX-852
> URL: https://issues.apache.org/jira/browse/PHOENIX-852
> Project: Phoenix
> Issue Type: Improvement
> Reporter: James Taylor
> Assignee: Maryann Xue
> Attachments: 852-2.patch, 852.patch, PHOENIX-852.patch
>
>
> Often times a join will occur from a child to a parent. Our current algorithm
> would do a full scan of one side or the other. We can do much better than
> that if the HashCache contains the PK (or even part of the PK) from the table
> being joined to. In these cases, we should drive the second scan through a
> skip scan on the server side.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
