add availability info for merge thread pool

Author: shainaraskas

docs/reference/elasticsearch/configuration-reference/thread-pool-settings.md

@@ -64,12 +64,14 @@ $$$search-throttled$$$`search_throttled`
 `flush`
 :   For [flush](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-flush) and [translog](/reference/elasticsearch/index-settings/translog.md) `fsync` operations. Thread pool type is `scaling` with a keep-alive of `5m` and a default maximum size of `min(5, (`[`# of allocated processors`](#node.processors)`) / 2)`.
 
-`merge`
+`merge` {applies_to}`stack: ga 9.1`
 :   For [merge](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-merge.html) operations of all the shards on the node. Thread pool type is `scaling` with a keep-alive of `5m` and a default maximum size of [`# of allocated processors`](#node.processors).
 
 `force_merge`
 :   For waiting on blocking [force merge](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-forcemerge) operations. Thread pool type is `fixed` with a size of `max(1, (`[`# of allocated processors`](#node.processors)`) / 8)` and an unbounded queue size.
 
+    In {{stack}} 9.0 and earlier, this thread pool is used for all force merge operations, not just blocking operations.
+
 `management`
 :   For cluster management. Thread pool type is `scaling` with a keep-alive of `5m` and a default maximum size of `5`.
 

docs/reference/elasticsearch/index-settings/merge.md

@@ -19,7 +19,9 @@ The merge process uses auto-throttling to balance the use of hardware resources
 ## Merge scheduling [merge-scheduling]
 
 The merge scheduler controls the execution of merge operations when they are needed.
-Merges run on the dedicated `merge` thread pool.
+
+
+{applies_to}`stack: ga 9.1` Merges run on the dedicated `merge` thread pool.
 Smaller merges are prioritized over larger ones, across all shards on the node.
 Merges are disk IO throttled so that bursts, while merging activity is otherwise low, are smoothed out in order to not impact indexing throughput.
 There is no limit on the number of merges that can be enqueued for execution on the thread pool.
@@ -28,21 +30,27 @@ However, beyond a certain per-shard limit, after merging is completely disk IO u
 The available disk space is periodically monitored, such that no new merge tasks are scheduled for execution when the available disk space is low.
 This is in order to prevent that the temporary disk space, which is required while merges are executed, completely fills up the disk space on the node.
 
+:::{note}
+In {{stack}} 9.0 and earlier, merges do not use a dedicated thread pool. Merges run in separate threads, and when the maximum number of threads is reached, further merges will wait until a merge thread becomes available.
+:::
+
+### Merge scheduler settings 
+
 The merge scheduler supports the following *dynamic* settings:
 
 `index.merge.scheduler.max_thread_count`
 :   The maximum number of threads on a **single** shard that may be merging at once. Defaults to `Math.max(1, Math.min(4, <<node.processors, node.processors>> / 2))` which works well for a good solid-state-disk (SSD). If your index is on spinning platter drives instead, decrease this to 1.
 
-`indices.merge.disk.check_interval`
+`indices.merge.disk.check_interval` {applies_to}`stack: ga 9.1`
 :   The time interval for checking the available disk space. Defaults to `5s`.
 
-`indices.merge.disk.watermark.high`
+`indices.merge.disk.watermark.high` {applies_to}`stack: ga 9.1`
 :   Controls the disk usage watermark, which defaults to `95%`, beyond which no merge tasks can start execution.
 The disk usage tally includes the estimated temporary disk space still required by all the currently executing merge tasks.
 Any merge task scheduled *before* the limit is reached continues execution, even if the limit is exceeded while executing
 (merge tasks are not aborted).
 
-`indices.merge.disk.watermark.high.max_headroom`
+`indices.merge.disk.watermark.high.max_headroom` {applies_to}`stack: ga 9.1`
 :   Controls the max headroom for the merge disk usage watermark, in case it is specified as percentage or ratio values.
 Defaults to `100GB` when `indices.merge.disk.watermark.high` is not explicitly set.
 This caps the amount of free disk space before merge scheduling is blocked.