phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maryann Xue (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-852) Optimize child/parent foreign key joins
Date Tue, 26 Aug 2014 17:46:01 GMT

    [ 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)

Mime
View raw message