[
https://issues.apache.org/jira/browse/PHOENIX-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134950#comment-14134950
]
James Taylor commented on PHOENIX-36:
-------------------------------------
[~ramkrishna] is nearing completion on PHOENIX-180 which gets rid of
maxConcurrency, targetConcurrency, and intra-region parallelism through
Bytes.split(), so I don't think it makes sense to pursue this anymore.
We could use some help on a lot of other things, though. HBASE-11292 would be
helpful - how about writing up your "undo type" which would cause the next key
value to be ignored? Another one might be an alternate non spooling parallel
scanner (see PHOENIX-539 for current solution) that keeps the Scanner open -
this would help for the ORDER BY case which isn't handled by the current
solution.
> Parallel Scaling
> ----------------
>
> Key: PHOENIX-36
> URL: https://issues.apache.org/jira/browse/PHOENIX-36
> Project: Phoenix
> Issue Type: Bug
> Reporter: Lars Hofhansl
>
> Right now the parallel scaling is defined by a constant (I think 32) that
> defines the number of threads/splits that can drive a single query.
> This number might be too large for a small cluster and too small for a large
> cluster; and this value should change as a cluster grows.
> One idea is to instead have a "scaling number". This would be a floating
> point number define the the number of threads to use per involved
> RegionServer.
> Say a query touches 10 RegionServers, than a scaling factor
> * of 1.0 would mean 10 threads
> * 0.1 means 1 thread
> * 10.0 means 100 thread
> * etc
> That way one can define the cost of a query in terms of cluster resources.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
