use_* MergeTree table settings

These settings are available in system.merge_tree_settings and are autogenerated from ClickHouse source.

use_adaptive_write_buffer_for_dynamic_subcolumns

Allow to use adaptive writer buffers during writing dynamic subcolumns to reduce memory usage

use_async_block_ids_cache

Obsolete setting, does nothing.

use_compact_variant_discriminators_serialization

Enables compact mode for binary serialization of discriminators in Variant data type. This mode allows to use significantly less memory for storing discriminators in parts when there is mostly one variant or a lot of NULL values.

use_const_adaptive_granularity

Non-const adaptive granularity (the default, index_granularity_bytes is not 0) keeps granules at a constant size in bytes, so their row count varies: for every written block, rows per granule is index_granularity_bytes divided by the average size of a row in that block, capped at index_granularity. Because it differs from granule to granule, the row count of every granule in the part has to be kept in memory, 8 bytes each, which on large tables adds up to tens of gigabytes.

Enabling constant adaptive granularity (this setting) keeps granules at a constant number of rows instead, so their size in bytes varies. The number is computed once from the average size of a row in the part being written, and a part stores that single value instead of one value per granule. Because all granules contain the same number of rows, no additional row count per granule needs to be stored.

The amount of memory currently spent on these values is reported by the TotalIndexGranularityBytesInMemory metric in system.asynchronous_metrics, and per part in system.parts.index_granularity_bytes_in_memory.

The setting is applied only to parts written after it was changed. Use ALTER TABLE … REWRITE PARTS to apply it to existing parts. Compact parts always use adaptive granularity.

use_metadata_cache

Obsolete setting, does nothing.

use_primary_key_cache

Use cache for primary index instead of saving all indexes in memory. Can be useful for very large tables