[
https://issues.apache.org/jira/browse/PHOENIX-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156317#comment-15156317
]
Lars Hofhansl commented on PHOENIX-2702:
----------------------------------------
Agree on the other format. Another option I was debating was this:
{noformat}
CLIENT 61-CHUNK PARALLEL 1-WAY RANGE SCAN ROWS 7069060 BYTES 629146340
{noformat}
{noformat}
CLIENT 61-CHUNK PARALLEL 1-WAY RANGE SCAN 7069060-ROWS 629146340-BYTES
{noformat}
The dash is possibly nicer as it makes parsing easier.
Another question about a nit:
When there are no rows estimated (the estimate is 0) I do not report rows or
bytes, I could report 0-ROWS and 0-BYTES instead, so the format is the same
always.
This would be nice to get into 4.7.0, as it would quite useful for us
(Salesforce).
> 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)
