Elastic search documentation about merge scheduling does not explicitly state that `index.merge.scheduler.max_thread_count` is a shard level property

[ahadadi]

Elastic search documentation about merge scheduling does not explicitly state that index.merge.scheduler.max_thread_count is a shard level property.
The documentation states that this is The maximum number of threads that may be merging at once but this is true only on a shard level.
Specifically, this recommendation: If your index is on spinning platter drives instead, decrease this to 1 leads one to assume that the node disk write concurrency will be 1 which is the case only with one shard and one index on the node.

[polyfractal]

I'm not sure I understand the issue? The setting is an index-level configuration, in that you configure it on a per-index basis. And the recommendation to decrease the number of merge threads if you're on a spinning drive is just to reduce IO contention, since spinning drives do not have nearly the random access IOPS that SSDs have.

What about the documentation should be updated? Not trying to be dense, just not sure I understand the issue :) Do you want it rephrased to something like:

The maximum number of threads on a single shard that may be merging at once

?

[ahadadi]

This rephrase is exactly what I had in mind :)

[ahadadi]

@polyfractal any thoughts about this?

[elasticmachine]

Pinging @elastic/es-distributed

[polyfractal]

This fell through my radar, sorry for the silence. @Sue-Gallagher, was this fixed or merged somewhere?

[Sue-Gallagher]

@polyfractal - no problem. All done PR #29686 :)