Re: merge policy vs commit rates

If you're going to do frequent commits or refreshes it means you care less about performance and more about durability and low-latency searching. In that case, it's best to index with only 1 thread: then every commit/refresh will only write one segment and you minimize the merge pressure. Adrien

Re: merge policy vs commit rates

IIUC, segments are actually written the first time when the ramBufferSizeMB is exceeded. If you can afford it you might increase that number. NOTE: I'm going from memory here so you should check That doesn't really address merging segments with deleted docs though. I do wonder what happens if

Re: merge policy vs commit rates

Optimizing for frequent changes sounds like a caching strategy, maybe “LRU merging”. Perhaps prefer merging segments that have not changed in a while? wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Aug 1, 2017, at 5:50 AM, Tommaso Teofili

Re: merge policy vs commit rates

Il giorno mar 1 ago 2017 alle ore 14:04 Adrien Grand ha scritto: > The trade-off does not sound simple to me. This approach could lead to > having more segments overall, making search requests and updates > potentially slower and more I/O-intensive since they have to iterate

Re: merge policy vs commit rates

The trade-off does not sound simple to me. This approach could lead to having more segments overall, making search requests and updates potentially slower and more I/O-intensive since they have to iterate over more segments? I'm not saying this is a bad idea, but it could have unexpected

merge policy vs commit rates

Hi all, lately I am looking a bit closer at merge policies, of course particularly at the tiered one, and I was wondering if we can mitigate the amount of possibly avoidable merges in high commit rates scenarios, especially when a high percentage of the commits happens on same docs. I've observed