Skip to main content

Overview

As part of the settings, ClickHouse offers the ability to place restrictions on query complexity. This helps protect against potentially resource-intensive queries, ensuring safer and more predictable execution, particularly when using the user interface. Almost all the restrictions only apply to SELECT queries, and for distributed query processing, restrictions are applied on each server separately. ClickHouse generally checks the restrictions only after data parts have been fully processed, rather than checking the restrictions for each row. This can result in a situation where restrictions are violated while the part is being processed.

overflow_mode settings

Most restrictions also have an overflow_mode setting, which defines what happens when the limit is exceeded, and can take one of two values:
  • throw: throw an exception (default).
  • break: stop executing the query and return the partial result, as if the source data ran out.
When a query is stopped by max_execution_time with break, some operations cannot return a partial result safely, so instead of a smaller result they stop without producing one. A function computing a single value stops without producing that value; whether the stop also reaches the client as a TIMEOUT_EXCEEDED error, or only as a missing result, depends on where the query was interrupted. A Memory-table mutation left incomplete by the timeout keeps the table unchanged and reports TIMEOUT_EXCEEDED. An INSERT may report QUERY_WAS_CANCELLED. Some operations that wait for other replicas or for background work do not stop at max_execution_time at all: a quorum write keeps waiting until its quorum is satisfied, or reports UNKNOWN_STATUS_OF_INSERT if insert_quorum_timeout elapses first.

group_by_overflow_mode settings

The group_by_overflow_mode setting also has the value any:
  • any : continue aggregation for the keys that got into the set, but do not add new keys to the set.

List of settings

The following settings are used for applying restrictions on query complexity.
Restrictions on the “maximum amount of something” can take a value of 0, which means that it is “unrestricted”.

Obsolete settings

The following settings are obsolete

max_pipeline_depth

Maximum pipeline depth. It Corresponds to the number of transformations that each data block goes through during query processing. Counted within the limits of a single server. If the pipeline depth is greater, an exception is thrown.
Last modified on August 12, 2026