[
https://issues.apache.org/jira/browse/PHOENIX-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16177396#comment-16177396
]
James Taylor commented on PHOENIX-4007:
---------------------------------------
One questions: why the extra call to initGuidePostDepth() in the
DefaultStatisticsCollector constructor?
{code}
diff --git
a/phoenix-core/src/main/java/org/apache/phoenix/schema/stats/DefaultStatisticsCollector.java
b/phoenix-core/src/main/java/org/apache/phoenix/schema/stats/DefaultStatisticsCollector.java
index b8ba75996..f9ee2757c 100644
---
a/phoenix-core/src/main/java/org/apache/phoenix/schema/stats/DefaultStatisticsCollector.java
+++
b/phoenix-core/src/main/java/org/apache/phoenix/schema/stats/DefaultStatisticsCollector.java
@@ -69,6 +69,7 @@ class DefaultStatisticsCollector implements
StatisticsCollector {
// Where to look for GUIDE_POSTS_WIDTH in SYSTEM.CATALOG
private final byte[] ptableKey;
private final RegionCoprocessorEnvironment env;
+ private boolean guidePostDepthInitialized;
private long guidePostDepth;
private long maxTimeStamp = MetaDataProtocol.MIN_TABLE_TIMESTAMP;
@@ -96,9 +97,10 @@ class DefaultStatisticsCollector implements
StatisticsCollector {
pName = MetaDataUtil.getViewIndexUserTableName(tableName);
}
ptableKey = SchemaUtil.getTableKeyFromFullName(pName);
+ initGuidepostDepth();
// Get the stats table associated with the current table on which the
CP is
{code}
One other comment - do you think we should write a test that uses it's own
clock to control the timestamp (see PartialIndexRebuilderIT) where you can
validate that the dates are as expected and checks that the min timestamp is
used in the explain plan? Your current asserts only check that the timestamp is
> 0.
> 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)
