[ https://issues.apache.org/jira/browse/PHOENIX-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14506358#comment-14506358 ]
ramkrishna.s.vasudevan edited comment on PHOENIX-1906 at 4/22/15 6:24 AM: -------------------------------------------------------------------------- [~giacomotaylor] I understand the real case here. It is probably better to highlight this in the HBase community through that JIRA. Let me do that. I have updated a patch there in HBASE-12790 after testing in a real cluster environment. Some interesting bug was found and fixed. As I said the only problem that I face is to write a real time test case, which I am figuring out a way probably that would work. was (Author: ram_krish): [~giacomotaylor] I understand the real case here. It is probably better to highlight this in the HBase community through that JIRA. Let me do that. I have updated a patch there in HBASE-12790 after testing in a real cluster environment. Some interesting bug was found and fixed. As I said the only problem that I face is to write a real time test case, which I am figuring out a way probably that would worm. > With large number of guideposts, queries that iterate over a small range gets > starved when running concurrently with larger queries > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: PHOENIX-1906 > URL: https://issues.apache.org/jira/browse/PHOENIX-1906 > Project: Phoenix > Issue Type: Bug > Reporter: Mujtaba Chohan > > Consider the scenario with a single region server. Table has 500 guide posts > (data is large enough that it won't fit either into HBase block or OS page > cache so it gets blocked on disk I/O during scans) and running the following > 2 queries concurrently with and without stats enabled: > {code}select count(*) from table{code} > {code}select * from table limit 10{code} > With stats *disabled*, average time for these two queries is 100sec and 100ms > respectively. However with stats long running count aggregate query time > drops to 8 second but limit query time increases to 3 seconds. Degradation in > limit query time is even more evident when concurrency level is further > increased. > [~jamestaylor] -- This message was sent by Atlassian JIRA (v6.3.4#6332)