[
https://issues.apache.org/jira/browse/PHOENIX-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453236#comment-16453236
]
James Taylor commented on PHOENIX-4686:
---------------------------------------
Thanks for the additional tests, [~abhishek.chouhan]. I've attached a new
version of the patch that:
- includes test for query with WHERE clause that doesn't get compiled out
- takes into account parallelized queries with LIMIT clause
One clarification, [~cody.mar...@gmail.com] - by "query with no where clause",
we really mean "query with where clause that does get compiled out". If the
WHERE IN clause is a point lookup, then that gets compiled into a scan without
a filter. On the other hand, if you have a WHERE clause that filters on a non
PK column, that'll end up as a filter (in which case we can't estimate the
rows/bytes scanned based on the LIMIT clause).
> 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
> Fix For: 4.14.0, 5.0.0
>
> Attachments: PHOENIX-4686-wip.master.patch,
> PHOENIX-4686.master.patch, PHOENIX-4686_v2.patch, PHOENIX-4686_wip1.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)
