[
https://issues.apache.org/jira/browse/PHOENIX-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156490#comment-15156490
]
Lars Hofhansl commented on PHOENIX-2702:
----------------------------------------
Lemme check in now for the next RC.
Quick vote on format?
I think I like this the best now:
{noformat}
CLIENT 61-CHUNK 7069060 ROWS 629146340 BYTES PARALLEL 1-WAY RANGE SCAN
{noformat}
Could also see:
{noformat}
CLIENT 61-CHUNK PARALLEL 1-WAY RANGE SCAN (7069060 ROWS 629146340 BYTES)
{noformat}
Or even (easier to parse):
{noformat}
CLIENT 61-CHUNK PARALLEL 1-WAY RANGE SCAN (rows=7069060 bytes=629146340)
{noformat}
Or could put {{7069060 ROWS 629146340 BYTES}} on it's own line, or even on it's
own line each... Oh so many options.
Since folks might parsing this, this would be a bit harder to change later.
Here's what PostgreSQL does:
http://www.postgresql.org/docs/9.0/static/sql-explain.html
And MySQL: https://dev.mysql.com/doc/refman/5.7/en/explain-output.html
Either way. Tell me what you think fits best with the current format and I'll
do that.
> Show estimate rows and bytes touched for explain plan.
> ------------------------------------------------------
>
> Key: PHOENIX-2702
> URL: https://issues.apache.org/jira/browse/PHOENIX-2702
> Project: Phoenix
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Attachments: PHOENIX-2702.txt
>
>
> We can already estimate the size of a table (both rows and uncompressed
> bytes) with q query like this:
> {code}
> SELECT physical_name AS table_name, SUM(guide_posts_row_count) AS est_rows,
> SUM(guide_posts_width) AS est_size from SYSTEM.STATS GROUP BY physical_name;
> {code}
> During the planning phase we have more information, though. So we can report
> the actual numbers for a query during an explain since we have that info
> there anyway (we filtered the guidepost already with the key info provided in
> the query).
> I might whip up a quick patch for this.
> (Could also go further and add a est_count, est_size UDF for this, but that
> would be a bit harder to get hooked up at the right places, I think, and the
> meaning would be ambiguous)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
