don't mention fixed throttling in the docs

docs/reference/cluster/update-settings.asciidoc

@@ -183,15 +183,6 @@ due to forced awareness or allocation filtering.
 `indices.recovery.max_bytes_per_sec`::
      See <<modules-indices>>
 
-[float]
-==== Store level throttling
-
-`indices.store.throttle.type`::
-      See <<index-modules-store>>
-
-`indices.store.throttle.max_bytes_per_sec`::
-      See <<index-modules-store>>
-
 [float]
 [[logger]]
 === Logger

docs/reference/index-modules/merge.asciidoc

@@ -7,12 +7,6 @@ where the index data is stored, and are immutable up to delete markers.
 Segments are, periodically, merged into larger segments to keep the
 index size at bay and expunge deletes.
 
-The more segments one has in the Lucene index means slower searches and
-more memory used. Segment merging is used to reduce the number of segments,
-however merges can be expensive to perform, especially on low IO environments.
-Merges can be throttled using <<store-throttling,store level throttling>>.
-
-
 [float]
 [[policy]]
 === Policy

docs/reference/index-modules/store.asciidoc

@@ -19,37 +19,6 @@ to the fact that there is no need for extra large JVM heaps (with their
 own consequences) for storing the index in memory.
 
 
-[float]
-[[store-throttling]]
-=== Store Level Throttling
-
-The way Lucene, the IR library elasticsearch uses under the covers,
-works is by creating immutable segments (up to deletes) and constantly
-merging them (the merge policy settings allow to control how those
-merges happen). The merge process happens in an asynchronous manner
-without affecting the indexing / search speed. The problem though,
-especially on systems with low IO, is that the merge process can be
-expensive and affect search / index operation simply by the fact that
-the box is now taxed with more IO happening.
-
-The store module allows to have throttling configured for merges (or
-all) either on the node level, or on the index level. The node level
-throttling will make sure that out of all the shards allocated on that
-node, the merge process won't pass the specific setting bytes per
-second. It can be set by setting `indices.store.throttle.type` to
-`merge`, and setting `indices.store.throttle.max_bytes_per_sec` to
-something like `5mb`. The node level settings can be changed dynamically
-using the cluster update settings API.  The default is disabled (set to `none`),
-in favor of <merge,auto throttle in the merge scheduler>.
-
-If specific index level configuration is needed, regardless of the node
-level settings, it can be set as well using the
-`index.store.throttle.type`, and
-`index.store.throttle.max_bytes_per_sec`. The default value for the type
-is `node`, meaning it will throttle based on the node level settings and
-participate in the global throttling happening. Both settings can be set
-using the index update settings API dynamically.
-
 [float]
 [[file-system]]
 === File system storage types

docs/reference/modules/indices.asciidoc

@@ -61,16 +61,3 @@ The following settings can be set to manage the recovery policy:
 `indices.recovery.max_bytes_per_sec`::
     defaults to `20mb`.
 
-[float]
-[[throttling]]
-=== Store level throttling
-
-The following settings can be set to control the store throttling:
-
-[horizontal]
-`indices.store.throttle.type`::
-    could be `merge` (default), `none` or `all`. See <<index-modules-store>>.
-
-`indices.store.throttle.max_bytes_per_sec`::
-    defaults to `20mb`.
-