---
title: Merge settings
description: A shard in Elasticsearch is a Lucene index, and a Lucene index is broken down into segments. Segments are internal storage elements in the index where...
url: https://www.elastic.co/elastic/docs-builder/docs/4614/reference/elasticsearch/index-settings/merge
products:
  - Elasticsearch
applies_to:
  - Elastic Stack: Generally available
---

# Merge settings
<admonition title="Settings supported in Serverless">
  Elastic Cloud Serverless projects [restrict the available Elasticsearch settings](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4614/deploy-manage/deploy/elastic-cloud/differences-from-other-elasticsearch-offerings#elasticsearch-differences-serverless-settings-availability) to a supported subset, identified with a `Serverless` badge next to the setting name. For a complete list of available index settings, refer to the [Serverless index settings list](https://www.elastic.co/elastic/docs-builder/docs/4614/reference/elasticsearch/index-settings/serverless).
</admonition>

A shard in Elasticsearch is a Lucene index, and a Lucene index is broken down into segments. Segments are internal storage elements in the index where the index data is stored, and are immutable. Smaller segments are periodically merged into larger segments to keep the index size at bay and to expunge deletes.
The merge process uses auto-throttling to balance the use of hardware resources between merging and other activities like search.

## Merge scheduling

The merge scheduler controls the execution of merge operations when they are needed.
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.
However, beyond a certain per-shard limit, after merging is completely disk IO un-throttled, indexing for the shard will itself be throttled until merging catches up.
<note>
  The `merge` thread pool and the periodic disk space check, which prevents new merges from starting when the available disk space is low, apply to all shards on a node. They are controlled by node-level settings. Refer to [Merge resource limits settings](https://www.elastic.co/elastic/docs-builder/docs/4614/reference/elasticsearch/configuration-reference/merge-settings).
</note>

The merge scheduler supports the following *dynamic* index settings:

<definitions>
  <definition term="index.merge.scheduler.max_thread_count">
    The maximum number of threads on a **single** shard that may be merging at once. Defaults to half the number of processors the JVM sees on the node, with a minimum of 1, which works well for a good solid-state-disk (SSD). If your index is on spinning platter drives instead, decrease this to 1. This default is independent of [`node.processors`](/elastic/docs-builder/docs/4614/reference/elasticsearch/configuration-reference/thread-pool-settings#node.processors). With `include_defaults`, the reported default is the unclamped value computed on the responding node; it may differ from the value a data node actually uses after clamping to `max_merge_count`, and from data nodes with a different processor count.
    If `max_thread_count` would exceed `index.merge.scheduler.max_merge_count`, Elasticsearch reduces it to `max_merge_count` when the index is opened or its settings change, and logs a warning. That can happen when `max_thread_count` is left unset and `max_merge_count` is set explicitly, especially across nodes with different processor counts, or when both are set with `max_thread_count` greater than `max_merge_count`.
  </definition>
</definitions>


<definitions>
  <definition term="index.merge.scheduler.max_merge_count">
    The maximum number of merges that may be running or waiting on a **single** shard at once. Defaults to `index.merge.scheduler.max_thread_count + 5`.
  </definition>
</definitions>


## Merge multi-threading

In general, merges are completed concurrently using multiple threads. Generally, each individual merge is single-threaded, but multiple merges can be run in parallel.
There are some exceptions and certain merges can utilize multiple threads within the merging operation itself. These threads will be assigned from the same pool as the background merge threads.
The following *dynamic* settings control multithreaded merging:

<definitions>
  <definition term="index.merge.intra_merge_parallelism_enabled Elastic Stack: Preview">
    Enables or disables intra-merge parallelism for data types that support it (e.g. `dense_vector`). Defaults to `false`.
  </definition>
</definitions>