async def forcemerge(
        self,
        *,
        index: t.Optional[t.Union[str, t.Sequence[str]]] = None,
        allow_no_indices: t.Optional[bool] = None,
        error_trace: t.Optional[bool] = None,
        expand_wildcards: t.Optional[
            t.Union[
                t.Sequence[
                    t.Union[str, t.Literal["all", "closed", "hidden", "none", "open"]]
                ],
                t.Union[str, t.Literal["all", "closed", "hidden", "none", "open"]],
            ]
        ] = None,
        filter_path: t.Optional[t.Union[str, t.Sequence[str]]] = None,
        flush: t.Optional[bool] = None,
        human: t.Optional[bool] = None,
        ignore_unavailable: t.Optional[bool] = None,
        max_num_segments: t.Optional[int] = None,
        only_expunge_deletes: t.Optional[bool] = None,
        pretty: t.Optional[bool] = None,
        wait_for_completion: t.Optional[bool] = None,
    ) -> ObjectApiResponse[t.Any]:
        """
        .. raw:: html

          <p>Force a merge.
          Perform the force merge operation on the shards of one or more indices.
          For data streams, the API forces a merge on the shards of the stream's backing indices.</p>
          <p>Merging reduces the number of segments in each shard by merging some of them together and also frees up the space used by deleted documents.
          Merging normally happens automatically, but sometimes it is useful to trigger a merge manually.</p>
          <p>WARNING: We recommend force merging only a read-only index (meaning the index is no longer receiving writes).
          When documents are updated or deleted, the old version is not immediately removed but instead soft-deleted and marked with a &quot;tombstone&quot;.
          These soft-deleted documents are automatically cleaned up during regular segment merges.
          But force merge can cause very large (greater than 5 GB) segments to be produced, which are not eligible for regular merges.
          So the number of soft-deleted documents can then grow rapidly, resulting in higher disk usage and worse search performance.
          If you regularly force merge an index receiving writes, this can also make snapshots more expensive, since the new documents can't be backed up incrementally.</p>
          <p><strong>Blocks during a force merge</strong></p>
          <p>Calls to this API block until the merge is complete (unless request contains <code>wait_for_completion=false</code>).
          If the client connection is lost before completion then the force merge process will continue in the background.
          Any new requests to force merge the same indices will also block until the ongoing force merge is complete.</p>
          <p><strong>Running force merge asynchronously</strong></p>
          <p>If the request contains <code>wait_for_completion=false</code>, Elasticsearch performs some preflight checks, launches the request, and returns a task you can use to get the status of the task.
          However, you can not cancel this task as the force merge task is not cancelable.
          Elasticsearch creates a record of this task as a document at <code>_tasks/&lt;task_id&gt;</code>.
          When you are done with a task, you should delete the task document so Elasticsearch can reclaim the space.</p>
          <p><strong>Force merging multiple indices</strong></p>
          <p>You can force merge multiple indices with a single request by targeting:</p>
          <ul>
          <li>One or more data streams that contain multiple backing indices</li>
          <li>Multiple indices</li>
          <li>One or more aliases</li>
          <li>All data streams and indices in a cluster</li>
          </ul>
          <p>Each targeted shard is force-merged separately using the force_merge threadpool.
          By default each node only has a single <code>force_merge</code> thread which means that the shards on that node are force-merged one at a time.
          If you expand the <code>force_merge</code> threadpool on a node then it will force merge its shards in parallel</p>
          <p>Force merge makes the storage for the shard being merged temporarily increase, as it may require free space up to triple its size in case <code>max_num_segments parameter</code> is set to <code>1</code>, to rewrite all segments into a new one.</p>
          <p><strong>Data streams and time-based indices</strong></p>
          <p>Force-merging is useful for managing a data stream's older backing indices and other time-based indices, particularly after a rollover.
          In these cases, each index only receives indexing traffic for a certain period of time.
          Once an index receive no more writes, its shards can be force-merged to a single segment.
          This can be a good idea because single-segment shards can sometimes use simpler and more efficient data structures to perform searches.
          For example:</p>
          <pre><code>POST /.ds-my-data-stream-2099.03.07-000001/_forcemerge?max_num_segments=1
          </code></pre>


        `<https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-forcemerge>`_

        :param index: A comma-separated list of index names; use `_all` or empty string
            to perform the operation on all indices
        :param allow_no_indices: Whether to ignore if a wildcard indices expression resolves
            into no concrete indices. (This includes `_all` string or when no indices
            have been specified)
        :param expand_wildcards: Whether to expand wildcard expression to concrete indices
            that are open, closed or both.
        :param flush: Specify whether the index should be flushed after performing the
            operation (default: true)
        :param ignore_unavailable: Whether specified concrete indices should be ignored
            when unavailable (missing or closed)
        :param max_num_segments: The number of segments the index should be merged into
            (default: dynamic)
        :param only_expunge_deletes: Specify whether the operation should only expunge
            deleted documents
        :param wait_for_completion: Should the request wait until the force merge is
            completed.
        """
        __path_parts: t.Dict[str, str]
        if index not in SKIP_IN_PATH:
            __path_parts = {"index": _quote(index)}
            __path = f'/{__path_parts["index"]}/_forcemerge'
        else:
            __path_parts = {}
            __path = "/_forcemerge"
        __query: t.Dict[str, t.Any] = {}
        if allow_no_indices is not None:
            __query["allow_no_indices"] = allow_no_indices
        if error_trace is not None:
            __query["error_trace"] = error_trace
        if expand_wildcards is not None:
            __query["expand_wildcards"] = expand_wildcards
        if filter_path is not None:
            __query["filter_path"] = filter_path
        if flush is not None:
            __query["flush"] = flush
        if human is not None:
            __query["human"] = human
        if ignore_unavailable is not None:
            __query["ignore_unavailable"] = ignore_unavailable
        if max_num_segments is not None:
            __query["max_num_segments"] = max_num_segments
        if only_expunge_deletes is not None:
            __query["only_expunge_deletes"] = only_expunge_deletes
        if pretty is not None:
            __query["pretty"] = pretty
        if wait_for_completion is not None:
            __query["wait_for_completion"] = wait_for_completion
        __headers = {"accept": "application/json"}
        return await self.perform_request(  # type: ignore[return-value]
            "POST",
            __path,
            params=__query,
            headers=__headers,
            endpoint_id="indices.forcemerge",
            path_parts=__path_parts,
        )

        .. raw:: html

          <p>Force a merge.
          Perform the force merge operation on the shards of one or more indices.
          For data streams, the API forces a merge on the shards of the stream's backing indices.</p>
          <p>Merging reduces the number of segments in each shard by merging some of them together and also frees up the space used by deleted documents.
          Merging normally happens automatically, but sometimes it is useful to trigger a merge manually.</p>
          <p>WARNING: We recommend force merging only a read-only index (meaning the index is no longer receiving writes).
          When documents are updated or deleted, the old version is not immediately removed but instead soft-deleted and marked with a &quot;tombstone&quot;.
          These soft-deleted documents are automatically cleaned up during regular segment merges.
          But force merge can cause very large (greater than 5 GB) segments to be produced, which are not eligible for regular merges.
          So the number of soft-deleted documents can then grow rapidly, resulting in higher disk usage and worse search performance.
          If you regularly force merge an index receiving writes, this can also make snapshots more expensive, since the new documents can't be backed up incrementally.</p>
          <p><strong>Blocks during a force merge</strong></p>
          <p>Calls to this API block until the merge is complete (unless request contains <code>wait_for_completion=false</code>).
          If the client connection is lost before completion then the force merge process will continue in the background.
          Any new requests to force merge the same indices will also block until the ongoing force merge is complete.</p>
          <p><strong>Running force merge asynchronously</strong></p>
          <p>If the request contains <code>wait_for_completion=false</code>, Elasticsearch performs some preflight checks, launches the request, and returns a task you can use to get the status of the task.
          However, you can not cancel this task as the force merge task is not cancelable.
          Elasticsearch creates a record of this task as a document at <code>_tasks/&lt;task_id&gt;</code>.
          When you are done with a task, you should delete the task document so Elasticsearch can reclaim the space.</p>
          <p><strong>Force merging multiple indices</strong></p>
          <p>You can force merge multiple indices with a single request by targeting:</p>
          <ul>
          <li>One or more data streams that contain multiple backing indices</li>
          <li>Multiple indices</li>
          <li>One or more aliases</li>
          <li>All data streams and indices in a cluster</li>
          </ul>
          <p>Each targeted shard is force-merged separately using the force_merge threadpool.
          By default each node only has a single <code>force_merge</code> thread which means that the shards on that node are force-merged one at a time.
          If you expand the <code>force_merge</code> threadpool on a node then it will force merge its shards in parallel</p>
          <p>Force merge makes the storage for the shard being merged temporarily increase, as it may require free space up to triple its size in case <code>max_num_segments parameter</code> is set to <code>1</code>, to rewrite all segments into a new one.</p>
          <p><strong>Data streams and time-based indices</strong></p>
          <p>Force-merging is useful for managing a data stream's older backing indices and other time-based indices, particularly after a rollover.
          In these cases, each index only receives indexing traffic for a certain period of time.
          Once an index receive no more writes, its shards can be force-merged to a single segment.
          This can be a good idea because single-segment shards can sometimes use simpler and more efficient data structures to perform searches.
          For example:</p>
          <pre><code>POST /.ds-my-data-stream-2099.03.07-000001/_forcemerge?max_num_segments=1
          </code></pre>


        `<https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-forcemerge>`_

        :param index: A comma-separated list of index names; use `_all` or empty string
            to perform the operation on all indices
        :param allow_no_indices: Whether to ignore if a wildcard indices expression resolves
            into no concrete indices. (This includes `_all` string or when no indices
            have been specified)
        :param expand_wildcards: Whether to expand wildcard expression to concrete indices
            that are open, closed or both.
        :param flush: Specify whether the index should be flushed after performing the
            operation (default: true)
        :param ignore_unavailable: Whether specified concrete indices should be ignored
            when unavailable (missing or closed)
        :param max_num_segments: The number of segments the index should be merged into
            (default: dynamic)
        :param only_expunge_deletes: Specify whether the operation should only expunge
            deleted documents
        :param wait_for_completion: Should the request wait until the force merge is
            completed.
        
elasticsearch/_async/client/indices.py