[
https://issues.apache.org/jira/browse/PHOENIX-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979298#comment-13979298
]
Lars Hofhansl commented on PHOENIX-36:
--------------------------------------
Looked at the Phoenix. Looks like this is quite easily doable. Will have a
patch soon.
I am planning to have the following:
# a global config option: phoenix.query.parallelScaling. When set it will
override the value set in phoenix.query.targetConcurrency
# A new query hint to set the scaling. Name? maybe SCALING(N)
Since this will be scaled with the number of involved region servers, should
the resulting concurrency still be subject to phoenix.query.maxConcurrency?
> 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.2#6252)
