[
https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111020#comment-14111020
]
Maryann Xue commented on PHOENIX-852:
-------------------------------------
I had not read the new WhereOptimizer code when I wrote that part.
One way is to let WhereOptimizer.KeyExpressionVisitor visit each join key
respectively and order those join keys by their key part starting position, or
do something similar to "andKeySlots()"?
In "newRowValueConstructorKeyParts()", there is this code: Does it mean if a
nested row value constructor cannot be handled here? So we have to flatten them
after constructing a new row value constructor for qualified join keys, right?
{code}
if (childExtractNodes.size() != 1 || childExtractNodes.get(0)
!= rvc.getChildren().get(i)) {
break;
}
{code}
And a more complicated case, for example, we have join keys: SUBSTR(rowKeyCol0,
1, 3) and rowKeyCol1, would it make sense to construct a
RowValueConstructor(SUBSTR(rowKeyCol0, 1, 3), rowKeyCol1)? Will WhereOptimizer
be able to handle that?
> 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)
