With a value of 1, you can only execute read requests (such as SELECT and SHOW). Requests for writing and changing settings (INSERT, SET) are prohibited.
With a value of 2, you can process read queries (SELECT, SHOW) and change settings (SET).
After enabling readonly mode, you can't disable it in the current session.
When using the GET method in the HTTP interface, 'readonly = 1' is set automatically. In other words, for queries that modify data, you can only use the POST method. You can send the query itself either in the POST body, or in the URL parameter.
The maximum amount of RAM to use for running a query on a single server.
In the default configuration file, the maximum is 10 GB.
The setting doesn't consider the volume of available memory or the total volume of memory on the machine.
The restriction applies to a single query within a single server.
You can use `SHOW PROCESSLIST` to see the current memory consumption for each query.
In addition, the peak memory consumption is tracked for each query and written to the log.
Memory usage is not monitored for the states of certain aggregate functions.
Memory usage is not fully tracked for states of the aggregate functions `min`, `max`, `any`, `anyLast`, `argMin`, `argMax` from `String` and `Array` arguments.
Memory consumption is also restricted by the parameters `max_memory_usage_for_user` and `max_memory_usage_for_all_queries`.
## max_memory_usage_for_user
The maximum amount of RAM to use for running a user's queries on a single server.
Default values are defined in [Settings.h](https://github.com/yandex/ClickHouse/blob/master/dbms/src/Interpreters/Settings.h#L244). By default, the amount is not restricted (`max_memory_usage_for_user = 0`).
See also the description of [max_memory_usage](#settings_max_memory_usage).
## max_memory_usage_for_all_queries
The maximum amount of RAM to use for running all queries on a single server.
Default values are defined in [Settings.h](https://github.com/yandex/ClickHouse/blob/master/dbms/src/Interpreters/Settings.h#L245). By default, the amount is not restricted (`max_memory_usage_for_all_queries = 0`).
See also the description of [max_memory_usage](#settings_max_memory_usage).
## max_rows_to_read
The following restrictions can be checked on each block (instead of on each row). That is, the restrictions can be broken a little.
When running a query in multiple threads, the following restrictions apply to each thread separately.
Maximum number of rows that can be read from a table when running a query.
## max_bytes_to_read
Maximum number of bytes (uncompressed data) that can be read from a table when running a query.
## read_overflow_mode
What to do when the volume of data read exceeds one of the limits: 'throw' or 'break'. By default, throw.
## max_rows_to_group_by
Maximum number of unique keys received from aggregation. This setting lets you limit memory consumption when aggregating.
## group_by_overflow_mode
What to do when the number of unique keys for aggregation exceeds the limit: 'throw', 'break', or 'any'. By default, throw.
Using the 'any' value lets you run an approximation of GROUP BY. The quality of this approximation depends on the statistical nature of the data.
## max_rows_to_sort
Maximum number of rows before sorting. This allows you to limit memory consumption when sorting.
## max_bytes_to_sort
Maximum number of bytes before sorting.
## sort_overflow_mode
What to do if the number of rows received before sorting exceeds one of the limits: 'throw' or 'break'. By default, throw.
## max_result_rows
Limit on the number of rows in the result. Also checked for subqueries, and on remote servers when running parts of a distributed query.
## max_result_bytes
Limit on the number of bytes in the result. The same as the previous setting.
## result_overflow_mode
What to do if the volume of the result exceeds one of the limits: 'throw' or 'break'. By default, throw.
Using 'break' is similar to using LIMIT.
## max_execution_time
Maximum query execution time in seconds.
At this time, it is not checked for one of the sorting stages, or when merging and finalizing aggregate functions.
## timeout_overflow_mode
What to do if the query is run longer than 'max_execution_time': 'throw' or 'break'. By default, throw.
## min_execution_speed
Minimal execution speed in rows per second. Checked on every data block when 'timeout_before_checking_execution_speed' expires. If the execution speed is lower, an exception is thrown.
## timeout_before_checking_execution_speed
Checks that execution speed is not too slow (no less than 'min_execution_speed'), after the specified time in seconds has expired.
## max_columns_to_read
Maximum number of columns that can be read from a table in a single query. If a query requires reading a greater number of columns, it throws an exception.
## max_temporary_columns
Maximum number of temporary columns that must be kept in RAM at the same time when running a query, including constant columns. If there are more temporary columns than this, it throws an exception.
## max_temporary_non_const_columns
The same thing as 'max_temporary_columns', but without counting constant columns.
Note that constant columns are formed fairly often when running a query, but they require approximately zero computing resources.
## max_subquery_depth
Maximum nesting depth of subqueries. If subqueries are deeper, an exception is thrown. By default, 100.
## max_pipeline_depth
Maximum pipeline depth. 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. By default, 1000.
## max_ast_depth
Maximum nesting depth of a query syntactic tree. If exceeded, an exception is thrown.
At this time, it isn't checked during parsing, but only after parsing the query. That is, a syntactic tree that is too deep can be created during parsing, but the query will fail. By default, 1000.
## max_ast_elements
Maximum number of elements in a query syntactic tree. If exceeded, an exception is thrown.
