clickhouse.guru
Tools · Ingestion

Part pressure calculator

Every INSERT that reaches a MergeTree table becomes at least one new part, per partition it touches, per table it lands in. Describe your insert pattern to see how many parts per second that is, how big they are, and how much room merges have before ClickHouse starts delaying and then rejecting inserts.

Defaults are ClickHouse's own: a 200 ms maximum flush timeout (adaptive down to 50 ms), a 10 MiB async buffer, 1000 active parts per partition before inserts are delayed and 3000 before they fail. Materialized views write their own parts into their target tables on every flush.

Flushes per second (source table)—
New parts per second, all tables—
New parts per day—
Average new part size—
If merges stopped: delay threshold in—
Verdict—

How it's computed

Without async inserts, every INSERT statement is flushed as it arrives. With them, the server buffers inserts per table and flushes when the buffer reachesasync_insert_max_data_size (10 MiB) or the busy timeout expires — so the flush rate is roughly the higher of 1000 ÷ timeout and bytes per second ÷ 10 MiB, never more than the insert rate itself. Each flush writes one part per partition it touches in the source table, and one more per materialized-view target.

The verdict follows the documentation's guidance for MergeTree: batch so that a table sees roughly one insert per second, with thousands of rows each. Above about ten new parts per second per table, merges are working constantly just to stand still, and a slowdown — a heavy query, a mutation, a slow disk — turns into TOO_MANY_PARTS.

This is a model, not a measurement. On a live server, the real numbers are one query away:

SELECT table,
       countIf(event_type = 'NewPart') / 3600 AS new_parts_per_second,
       countIf(event_type = 'MergeParts')  / 3600 AS merges_per_second,
       formatReadableSize(avgIf(size_in_bytes, event_type = 'NewPart')) AS avg_new_part
FROM system.part_log
WHERE event_time > now() - INTERVAL 1 HOUR
GROUP BY table
ORDER BY new_parts_per_second DESC;

Related: Insert batching and too many parts, Async inserts explained and thesparse index calculator.