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

Reply via email to