[
https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090108#comment-14090108
]
Maryann Xue commented on PHOENIX-852:
-------------------------------------
We now need to introduce something like dynamic compilation -- compilation that
happens in the middle of an execution. And it is going to used by "IN / NOT IN"
sub-queries as well. I am thinking if it is possible to merge scan ranges so
that we can avoid compiling those static where conditions but only compile
those dynamic ones?
Do we need a size limit for such optimizations? The skip scan range list might
be too long, or the InListExpression's hashset could be too big and unlike
hash-cache it escapes the memory manager.
However the hash cache thing in join queries is inevitable I think, for there
could be 1-to-many mappings between two tables, which means the join semantics
is not totally equivalent to IN clause.
> 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
>
> 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)
