[
https://issues.apache.org/jira/browse/PHOENIX-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168309#comment-16168309
]
Samarth Jain commented on PHOENIX-4007:
---------------------------------------
This patch removes the differentiation. Both the cases are now denoted by the
estimates (bytes/rows scanned) being reported as null. And we are not able to
provide estimates in both of these cases.
This becomes important when we are querying two tables - one which has
guideposts and the other doesn't. In such a scenario I took the approach of
reporting that we cannot provide an estimate. I didn't want to report the
estimate by just using one table's guideposts. For ex - SELECT * FROM
TABLE_WITH_GUIDEPOSTS UNION ALL SELECT * FROM TABLE_WITH_NO_GUIDEPOSTS
> 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
>
>
> 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)
