use_query_cache
If turned on,SELECT queries may utilize the query cache. Parameters enable_reads_from_query_cache
and enable_writes_to_query_cache control in more detail how the cache is used.
Possible values:
- 0 - Disabled
- 1 - Enabled
use_query_condition_cache
Enable the query condition cache. The cache stores ranges of granules in data parts which do not satisfy the condition in theWHERE clause,
and reuse this information as an ephemeral index for subsequent queries.
Possible values:
- 0 - Disabled
- 1 - Enabled
use_query_condition_cache_for_time_conditions
Enable the query condition cache for conditions that involve the current time, e.g.WHERE time >= now() - INTERVAL 10 DAY, when reading from MergeTree tables. Reads from files and object storage (file, s3, and similar) use the query condition cache only for deterministic conditions and are not affected by this setting.
Such conditions are non-deterministic (they change with the clock), so they cannot be cached directly. Instead, a deterministic condition is derived from them by rounding the folded current-time constant onto a time grid, e.g. WHERE time >= '2026-08-09 12:34:56' becomes WHERE time >= '2026-08-09 00:00:00' (rounding down for cache reads, up for cache writes, which keeps the cache sound). The grid step is proportional to the distance between the constant and the current time (see query_condition_cache_time_condition_grid_factor), clamped to between one second and one day.
If the constant is already aligned to the grid (e.g. WHERE time >= today() - 10 or WHERE time >= toStartOfDay(now())), the cache is effective for the whole grid cell, e.g. until the end of the day. Otherwise, the cache is reused only for lower bounds on the time, e.g. WHERE time >= now() - INTERVAL 10 DAY: cache entries written during one grid cell are used during the next one. An unaligned upper bound such as WHERE time < now(), alone or as a part of a sliding window like WHERE time >= now() - INTERVAL 10 DAY AND time < now(), is not reused by later queries, because their condition is not contained in the condition of the earlier ones.
This setting has no effect unless use_query_condition_cache is also enabled.
Possible values:
- 0 - Disabled
- 1 - Enabled
use_query_condition_cache_for_top_k
Enable the query condition cache for queries that use theORDER BY <column> LIMIT n (TopK) optimization (dynamic filtering or skip-index based). When disabled, such reads neither consult nor populate the cache.
Such queries can drop granules during execution depending on the running threshold, so their cache entries are partitioned by the TopK plan parameters and by the set of parts read (for a File table, by the set of files read and their versions; for a data lake table, by its snapshot). This setting has no effect unless use_query_condition_cache is also enabled.
Possible values:
- 0 - Disabled
- 1 - Enabled