[
https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14104946#comment-14104946
]
James Taylor commented on PHOENIX-852:
--------------------------------------
Thanks for the quick turn around on the patch, [~maryannxue]. Instead of adding
new hints, how about if we either name them similar to the ones we have or even
use them directly if possible. For example, we have these two:
{code}
/**
* Forces a range scan to be used to process the query.
*/
RANGE_SCAN,
/**
* Forces a skip scan to be used to process the query.
*/
SKIP_SCAN,
{code}
We could just use those to drive this decision too, but then this would apply
to the RHS and LHS query, so perhaps that's not so good. A quick and dirty way
would be to tack something on to these, like RANGE_SCAN_HASH_JOIN and
SKIP_SCAN_HASH_JOIN. Another way might be to allow these hints to be scoped to
a table/alias, like SKIP_SCAN(my_table). Not sure how to communicate that it
doesn't apply to the RHS table, but does apply to the join processing. Maybe
just the quick-and-dirty way for consistency?
Thoughts?
> 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.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)
