[
https://issues.apache.org/jira/browse/HIVE-15881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864718#comment-15864718
]
Thomas Poepping commented on HIVE-15881:
----------------------------------------
[~spena] Good point. To take into account everyone's ideas, maybe something
like {{hive.exec.input.listing.max.threads}}? It's tough, but I'm not sure
there will be one obvious best answer, I think each one will have pros and cons
compared to any other.
Agree with [~yalovyyi]'s suggestion as well. What would we want default to be?
Looking through {{HiveConf}}, the different {{*.max.threads}} values are:
* {{METASTORESERVERMAXTHREADS("hive.metastore.server.max.threads", 1000,}}
* {{HIVE_SERVER2_WEBUI_MAX_THREADS("hive.server2.webui.max.threads", 50, "The
max HiveServer2 WebUI threads"),}}
*
{{LLAP_DAEMON_AM_REPORTER_MAX_THREADS("hive.llap.daemon.am-reporter.max.threads",
4,}}
So.. all over the place. How would we decide on a suitable default? Or maybe,
the default is "as many as possible" and it can be lowered by users themselves?
> Use new thread count variable name instead of mapred.dfsclient.parallelism.max
> ------------------------------------------------------------------------------
>
> Key: HIVE-15881
> URL: https://issues.apache.org/jira/browse/HIVE-15881
> Project: Hive
> Issue Type: Task
> Components: Query Planning
> Reporter: Sergio Peña
> Assignee: Sergio Peña
> Priority: Minor
>
> The Utilities class has two methods, {{getInputSummary}} and
> {{getInputPaths}}, that use the variable {{mapred.dfsclient.parallelism.max}}
> to get the summary of a list of input locations in parallel. These methods
> are Hive related, but the variable name does not look it is specific for Hive.
> Also, the above variable is not on HiveConf nor used anywhere else. I just
> found a reference on the Hadoop MR1 code.
> I'd like to propose the deprecation of {{mapred.dfsclient.parallelism.max}},
> and use a different variable name, such as
> {{hive.get.input.listing.num.threads}}, that reflects the intention of the
> variable. The removal of the old variable might happen on Hive 3.x
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
