[ 
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)

Reply via email to