# How to predict or estimate merge will be triggered

**URL:** <https://discuss.elastic.co/t/how-to-predict-or-estimate-merge-will-be-triggered/56823>\
**Category:** Elasticsearch\
**Created:** [July 31, 2016, 1:50pm UTC](https://discuss.elastic.co/t/how-to-predict-or-estimate-merge-will-be-triggered/56823 "2016-07-31T13:50:37Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![itplayer](https://avatars.discourse-cdn.com/v4/letter/i/d26b3c/32.png) [@itplayer](https://discuss.elastic.co/u/itplayer)\
**Post date:** [July 31, 2016, 1:50pm UTC](https://discuss.elastic.co/t/how-to-predict-or-estimate-merge-will-be-triggered/56823/1 "2016-07-31T13:50:37Z")

</div>

Is there a way to predict or estimate merge will be triggered during indexing time?  
I use Elasticsearch 1.7.2 and all settings about merge is by default.

---

<div class="post-metadata">

**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\
**Post date:** [July 31, 2016, 2:34pm UTC](https://discuss.elastic.co/t/how-to-predict-or-estimate-merge-will-be-triggered/56823/2 "2016-07-31T14:34:43Z")

</div>

Not effectively.

---

<div class="post-metadata">

**Author:** ![taras](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/taras/32/507_2.png) [@taras](https://discuss.elastic.co/u/taras)\
**Post date:** [August 1, 2016, 1:23am UTC](https://discuss.elastic.co/t/how-to-predict-or-estimate-merge-will-be-triggered/56823/3 "2016-08-01T01:23:28Z")

</div>

There is a way to avoid merges. That is by setting [refresh\_interval](https://www.elastic.co/guide/en/elasticsearch/reference/1.7/index-modules.html#index-modules-settings) to _-1_. That will suspend automatic merging, and making your freshly indexed documents visible. If you're doing a bulk data load, that is a good way to speed up your indexing.

There is also a way to [optimize](https://www.elastic.co/guide/en/elasticsearch/reference/1.7/indices-optimize.html#optimize-parameters) / force merge afterwards, but in practice that should really be used only when you're pretty sure you're done modifying the index and it is now _historical_ data.

Hope that helps

---

<div class="post-metadata">

**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\
**Post date:** [August 1, 2016, 1:40am UTC](https://discuss.elastic.co/t/how-to-predict-or-estimate-merge-will-be-triggered/56823/4 "2016-08-01T01:40:58Z")

</div>

Refresh interval won't always prevent refreshes. If you run out of memory  
budgeted to keep documents in memory before a refresh elasticsearch will  
trigger a refresh.

Refreshes aren't merges either, though you are right in that not refreshing  
won't create the segments which have to later be merged.

You can control merges somewhat with merge throttling and the size of the  
merge thread pool but you can't really predict or prevent them. At, least  
not in any sustainable, practical way.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 10:31pm UTC](https://discuss.elastic.co/t/how-to-predict-or-estimate-merge-will-be-triggered/56823/5 "2017-07-05T22:31:24Z")

</div>