phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4007) Surface time at which byte/row estimate information was computed in explain plan output
Date Tue, 26 Sep 2017 06:26:00 GMT

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

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/12889010/PHOENIX-4007_v9.patch
  against master branch at commit 94601de5f5f966fb8bcd1a069409bee460bf2400.
  ATTACHMENT ID: 12889010

    {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="
+                        + " (orgId CHAR(15) NOT NULL, pk2 integer NOT NULL, c1.a bigint,
c2.b bigint CONSTRAINT PK PRIMARY KEY "
+                "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="
+                // If there are no guide posts within the query range, we use the estimateInfoTimestamp
+                while (intersectWithGuidePosts && (endKey.length == 0 || currentGuidePost.compareTo(endKey)
<= 0)) {
+                    Scan newScan = scanRanges.intersectScan(scan, currentKeyBytes, currentGuidePostBytes,
keyOffset,
+                        scans = addNewScan(parallelScans, scans, newScan, currentGuidePostBytes,
false, regionLocation);

     {color:red}-1 core tests{color}.  The patch failed these unit tests:
     

Test results: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1479//testReport/
Console output: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1479//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,
PHOENIX-4007_v9.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)

Mime
View raw message