Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Thu, 21 Sep 2017 08:17:00 +0000 (UTC)
From: "Hadoop QA (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13086160.1499752703000.164549.1505981820335@Atlassian.JIRA>
In-Reply-To: <JIRA.13086160.1499752703000@Atlassian.JIRA>
References: <JIRA.13086160.1499752703000@Atlassian.JIRA> <JIRA.13086160.1499752703807@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-4007) Surface time at which byte/row
 estimate information was computed in explain plan output
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 21 Sep 2017 08:17:05 -0000


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

Hadoop QA commented on PHOENIX-4007:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12888212/PHOENIX-4007_v8.patch
  against master branch at commit 3fb104ee56518ca066672e199bff1ed4f4bd9a7e.
  ATTACHMENT ID: 12888212

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 9 new or modified tests.

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of javac compiler warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number of release audit warnings.

    {color:red}-1 lineLengths{color}.  The patch introduces the following lines longer than 100:
    +                    + " ( k INTEGER, c1.a bigint,c2.b bigint CONSTRAINT pk PRIMARY KEY (k)) GUIDE_POSTS_WIDTH = 0");
+                    + " ( k INTEGER, c1.a bigint,c2.b bigint CONSTRAINT pk PRIMARY KEY (k)) GUIDE_POSTS_WIDTH=" + guidePostWidth);
+                            + " (k INTEGER PRIMARY KEY, c1.a bigint, c2.b bigint) GUIDE_POSTS_WIDTH="
+                        + " (orgId CHAR(15) NOT NULL, pk2 integer NOT NULL, c1.a bigint, c2.b bigint CONSTRAINT PK PRIMARY KEY (ORGID, PK2)) MULTI_TENANT=true, GUIDE_POSTS_WIDTH="
+                "CLIENT 1-CHUNK 0 ROWS 20 BYTES PARALLEL 1-WAY FULL SCAN OVER " + physicalTableName + "\n" +
+        String stats = columnEncoded && !mutable  ? "4-CHUNK 1 ROWS 38 BYTES" : "3-CHUNK 0 ROWS 20 BYTES";
+                            + " ( k INTEGER, c1.a bigint,c2.b bigint CONSTRAINT pk PRIMARY KEY (k)) GUIDE_POSTS_WIDTH="
+                || (lhsPlan.getEstimatedRowsToScan() == null || rhsPlan.getEstimatedRowsToScan() == null)
+                || (lhsPlan.getEstimateInfoTimestamp() == null || rhsPlan.getEstimateInfoTimestamp() == null)) {
+                // If there are no guide posts within the query range, we use the estimateInfoTimestamp

    {color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1467//testReport/
Console output: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1467//console

This message is automatically generated.

> Surface time at which byte/row estimate information was computed in explain plan output
> ---------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-4007
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4007
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Samarth Jain
>            Assignee: Samarth Jain
>         Attachments: PHOENIX-4007_v1.patch, PHOENIX-4007_v2.patch, PHOENIX-4007_v3.patch, PHOENIX-4007_v4.patch, PHOENIX-4007_v6.patch, PHOENIX-4007_v7.patch, PHOENIX-4007_v8.patch
>
>
> As part of PHOENIX-3822, we surfaced byte and row estimates for queries in explain plan. Since we collect this information through stats collection, it would also be helpful to surface when this information was last updated to reflect its freshness. We already store last_stats_update_time in SYSTEM.STATS. So the task would be essentially surfacing last_stats_update_time as another column in the explain plan result set.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)