[
https://issues.apache.org/jira/browse/PHOENIX-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16442565#comment-16442565
]
Abhishek Singh Chouhan commented on PHOENIX-4686:
-------------------------------------------------
[~jamestaylor] Have attached a WIP patch. Please have a look and let me know if
this is in the right direction :)
Basic idea of the patch is to handle the two cases using stats for
parallelization(and in turn having scans b/w guide posts that will have the
page filter with the limit specified) and no stats parallelization (where we'll
have a scan spanning multiple gps in which case adjust the estimates that we've
collected in the loop above). For adjustment of stats in both the cases i've
used the simple method of estimating single row size (bytes in gp/rows in gp)
and multiplying by the perscan limit that we're pushing down in the scan.
> Phoenix stats does not account for server side limit push downs
> ---------------------------------------------------------------
>
> Key: PHOENIX-4686
> URL: https://issues.apache.org/jira/browse/PHOENIX-4686
> Project: Phoenix
> Issue Type: Bug
> Reporter: Abhishek Singh Chouhan
> Assignee: Abhishek Singh Chouhan
> Priority: Major
> Attachments: PHOENIX-4686-wip.master.patch
>
>
> For a query like SELECT * FROM FOO LIMIT 10 the EST_BYTES_READ does not take
> into account a limit correctly when there's no WHERE clause (or a WHERE
> clause that gets compiled out into start/stop row key on the scan).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
