phoenix-dev mailing list archives

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

    [ 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)

Mime
View raw message