phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas D'Silva (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-1812) Only sync table metadata when necessary
Date Wed, 10 Jun 2015 19:04:02 GMT

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

Thomas D'Silva commented on PHOENIX-1812:
-----------------------------------------

[~jamestaylor]
I have uploaded a second patch. I modified PTableRef  to include  resolvedTimeStamp. 

The extra RPC call to getTable for queries was happening because in QueryCompiler.compileSingleFlatQuery
the following if statement was evaluating to false event though both TableRefs references
the same table, one of them had a null alias.

{code}
        // Don't pass groupBy when building where clause expression, because we do not want
to wrap these
        // expressions as group by key expressions since they're pre, not post filtered.
        if (innerPlan == null && !tableRef.equals(resolver.getTables().get(0))) {
            context.setResolver(FromCompiler.getResolverForQuery(select, this.statement.getConnection()));
        }
{code}

it works correctly when I modified TableRef.equals to not compare the alias if one of them
is null:

{code}
-        // FIXME: a null alias on either side should mean a wildcard and should not fail
the equals check
-        if ((alias == null && other.alias != null) || (alias != null && !alias.equals(other.alias)))
return false;
+        // a null alias on either side should mean a wildcard and should not fail the equals
check
+        if ((alias != null && other.alias != null && !alias.equals(other.alias)))
return false;
{code}

In UpdateCacheIT testUpdateCacheForTxnTable()

For transactional tables  in PhoenixStatment.executeQuery() since the plan is compiled before
a transaction is started, 
the first call to connection.getTable() will not have a valid txn timestamp, the second call
will have a valid txn timestamp, and the third will use the table cached at the txn timestamp
for a total of two rpcs. 
I think we can't change executeQuery() to start a transaction before compiling the plan, because
then it will always make a rpc call to the txn manager (even if the query doesnt have any
transactional tables).


> Only sync table metadata when necessary
> ---------------------------------------
>
>                 Key: PHOENIX-1812
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1812
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: James Taylor
>            Assignee: Thomas D'Silva
>         Attachments: PHOENIX-1812.patch
>
>
> With transactions, we hold the timestamp at the point when the transaction was opened.
We can prevent the MetaDataEndpoint getTable RPC in MetaDataClient.updateCache() to check
that the client has the latest table if we've already checked at the current transaction ID
timestamp. We can keep track of which tables we've already updated in PhoenixConnection.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message