[ 
https://issues.apache.org/jira/browse/PHOENIX-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl updated PHOENIX-2702:
-----------------------------------
    Attachment: PHOENIX-2702.txt

Here's a trivial patch.
* Simply reports ROWS and BYTES with explain.
* Note that GuidePostsInfoBuilder had a bug, the row count was never loaded, 
guess nobody uses that, yet :)
* It's less clean than I'd like. Added non-final estimatedSize, estimatedRows 
to BaseResultIterators
* rows/bytes is only displayed when N-CHUNK is displayed, and then only if the 
estimate is > 0.

The estimates are quite nice! We can now easily get row/size estimates for 
tenants, or anything really that can narrowed through a prefix of the key.
300MB guide posts are fairly course, though. I think we should at least revert 
back to 100MB... I tried with 10MB posts, and the rows/size estimates were 
quite accurate!

[~giacomotaylor], lemme know what you think of this patch.


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

Reply via email to