[
https://issues.apache.org/jira/browse/PHOENIX-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16443655#comment-16443655
]
James Taylor commented on PHOENIX-4686:
---------------------------------------
Thanks for the wip patch, [~abhishek.chouhan]. I'd recommend following the same
pattern that we have for point lookups. Just let the existing code execute
as-is (we need it to calculate the scans anyway), and then at the end (if we're
pushing a PageFilter, or we could detect it based on the QueryPlan as well),
just multiple the row size estimate by the limit to calculate the estimated
bytes scanned. Also, I think we might need a new ExplainPlan attribute like
EST_BASED_ON_STATS which is set to false in this case and in the case of point
lookups (since in neither case would we be relying on stats for the estimate).
The reason this is useful is that in these cases, the EST_INFO_TS being null
can be ignored by the client.
> 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)
