Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Wed, 10 Jun 2015 19:04:02 +0000 (UTC)
From: "Thomas D'Silva (JIRA)" <jira@apache.org>
To: dev@phoenix.incubator.apache.org
Message-ID: <JIRA.12788355.1428253866000.39691.1433963042514@Atlassian.JIRA>
In-Reply-To: <JIRA.12788355.1428253866000@Atlassian.JIRA>
References: <JIRA.12788355.1428253866000@Atlassian.JIRA>
 <JIRA.12788355.1428253866777@arcas>
Subject: [jira] [Commented] (PHOENIX-1812) Only sync table metadata when
 necessary
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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