phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4686) Phoenix stats does not account for server side limit push downs
Date Wed, 25 Apr 2018 23:34:00 GMT


James Taylor commented on PHOENIX-4686:

Thanks for the additional tests, [~abhishek.chouhan]. I've attached a new version of the patch
- includes test for query with WHERE clause that doesn't get compiled out
- takes into account parallelized queries with LIMIT clause

One clarification, [] - 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:
>             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,
> 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

View raw message