[
https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14105721#comment-14105721
]
James Taylor commented on PHOENIX-852:
--------------------------------------
It'll always be the case that an optimization choice was wrong, even if we have
stats. We just have to choose what we *think* is the best choice and (for now)
fallback on hints to override.
I think for the default case, we can have a compromise solution. If the RHS
table has a filter *and* a skip scan can be done on the LHS, then we default to
the skip scan. If the RHS has no filter, then we default to a range scan.
> 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)
