[
https://issues.apache.org/jira/browse/PHOENIX-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168384#comment-16168384
]
Samarth Jain commented on PHOENIX-4007:
---------------------------------------
I am not too sure if we should have the differentiation in first place. We use
the two fields for providing estimate and saying that the query is going to
scan 0 rows and 0 bytes isn't always correct. Consider the case when the table
does have guideposts but it is trying to scan data that is outside the range of
existing data. In that case too, we would end up reporting 0 bytes and 0 rows.
So really the user can't know if it is the case of "no guideposts because of
large guidepost width" or is it that the query is effectively not going to scan
anything. With my patch we report null if the table has no guideposts and 0 if
the table has guidepost but the query is outside the current data range.
> 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)
