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 Thu, 14 Aug 2014 22:17:18 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14097782#comment-14097782
] 

Maryann Xue commented on PHOENIX-852:
-------------------------------------

I see. So the below code is now what handles partial match for IN clause, right?

{code}
            // We can only optimize a row value constructor that is fully qualified
            if (childSlot.getPKSpan() > 1 && !isFullyQualified(childSlot.getPKSpan()))
{
                // Just return a key part that has the min/max of the IN list, but doesn't
                // extract the IN list expression.
                return newKeyParts(childSlot, (Expression)null, Collections.singletonList(
                        KeyRange.getKeyRange(
                                ByteUtil.copyKeyBytesIfNecessary(node.getMinKey()), true,
                                ByteUtil.copyKeyBytesIfNecessary(node.getMaxKey()), true)),
null);
            }
{code}

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

Mime
View raw message