Use case

A user can specify too large background_pool_size, and merges can constantly fail and make no progress due to memory exhaustion.

Horizontal merges of wide tables with many LowCardinality or AggregateFunction columns can have high memory usage.

Mutations can have high memory usage if they use complex expressions for updating or deleting.

We should not let too many merges be processed at once if the memory usage is high.

Implementation proposal

Add two global configuration options:

merges_memory_usage_soft_limit and merges_memory_usage_soft_limit_to_ram_ratio

similarly to max_server_memory_usage and max_server_memory_usage_to_ram_ratio. The latter setting should be 0.5 by default.

Track the total memory usage by merges.

Caveat: it cannot be done with MemoryTracker. Because a merge operation can free some memory (primary keys) that were allocated outside of the context of the merge, the resulting memory usage at the end of the merge can be negative. We cannot reset it to zero at the end of the merge operation because the MemoryTracker of the merge is attached to the server's global MemoryTracker and should be consistent with it. The only reasonable way is to track the sum of memory usage by active merges separately.

If the current memory usage by merges is higher than the soft limit, do not start new merges.