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