[jira] [Commented] (PHOENIX-3822) Surface byte and row estimates in a machine readable way when doing EXPLAIN PLAN

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3822:
---------------------------------------

Thanks for the updates, [~samarthjain]. Couple of minor comments:
- Are these PhoenixRuntime static constants used anywhere and if not, how about 
reverting that change?
{code}
--- a/phoenix-core/src/main/java/org/apache/phoenix/util/PhoenixRuntime.java
+++ b/phoenix-core/src/main/java/org/apache/phoenix/util/PhoenixRuntime.java
@@ -66,6 +66,7 @@ import org.apache.phoenix.expression.RowKeyColumnExpression;
 import org.apache.phoenix.jdbc.PhoenixConnection;
 import org.apache.phoenix.jdbc.PhoenixPreparedStatement;
 import org.apache.phoenix.jdbc.PhoenixResultSet;
+import org.apache.phoenix.jdbc.PhoenixStatement;
 import org.apache.phoenix.monitoring.GlobalClientMetrics;
 import org.apache.phoenix.monitoring.GlobalMetric;
 import org.apache.phoenix.query.QueryConstants;
@@ -186,6 +187,20 @@ public class PhoenixRuntime {
     public static final String REQUEST_METRIC_ATTRIB = "RequestMetric";
 
     /**
+     * Use this column name on the row returned by explain plan result set to 
get estimate of number
+     * of bytes read.
+     */
+    public static final String EXPLAIN_PLAN_ESTIMATED_BYTES_READ_COLUMN =
+            PhoenixStatement.EXPLAIN_PLAN_BYTES_ESTIMATE_COLUMN_ALIAS;
+
+    /**
+     * Use this column name on the row returned by explain plan result set to 
get estimate of number
+     * of rows read.
+     */
+    public static final String EXPLAIN_PLAN_ESTIMATED_ROWS_READ_COLUMN =
+            PhoenixStatement.EXPLAIN_PLAN_ROWS_COLUMN_ALIAS;
+
+    /**
      * All Phoenix specific connection properties
      * TODO: use enum instead
      */
{code}
- In cases like UPSERT VALUES and DELETE where we have the entire PK, we should 
return 0 for estimated bytes and rows scanned. IMHO, returning null should be 
reserved for cases in which we have no stats, so we *don't know* how what the 
answer is.
{code}
+       @Test
+    public void testBytesRowsForUpsertValues() throws Exception {
+        String sql = "UPSERT INTO " + tableA + " VALUES (?, ?, ?)";
+        List<Object> binds = Lists.newArrayList();
+        binds.add(99);
+        binds.add(99);
+        binds.add(99);
+        try (Connection conn = DriverManager.getConnection(getUrl())) {
+            Pair<Long, Long> info = getByteRowEstimates(conn, sql, binds);
+            assertNull(info.getSecond());
+            assertNull(info.getFirst());
+        }
+    }
{code}
- Same thing for statements that don't issue any scans, like TRACE, etc. We 
should return 0 in these cases. We should consider having an abstract base 
class for these anonymous QueryPlan classes since many methods all return the 
same thing (to cut down on the copy/paste).

> Surface byte and row estimates in a machine readable way when doing EXPLAIN 
> PLAN
> --------------------------------------------------------------------------------
>
>                 Key: PHOENIX-3822
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3822
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Samarth Jain
>            Assignee: Samarth Jain
>         Attachments: PHOENIX-3822.patch, PHOENIX-3822_v2.patch, 
> PHOENIX-3822_v3.patch, PHOENIX-3822_v4.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)