ClickHouse Vectorized Query Processing: 5 Mechanics, Measured in the Lab

Inside the engine

Blocks, columns and processors: how the data moves

A Block is ClickHouse’s in-memory unit of work: a set of columns, each an IColumn backed by contiguous arrays, plus their types and names. Numeric columns are plain arrays; strings and arrays use an offsets vector and a data vector. Functions never modify a column in place, they return a new one, which keeps every inner loop simple and branch-light.

• On disk, MergeTree splits each part into granules of 8,192 rows, and compresses columns in blocks of roughly 64 KB to 1 MB of uncompressed data. See our ClickHouse MergeTree guide for how granules and marks drive index lookups.
• In memory, readers assemble blocks of up to max_block_size rows, 65,409 by default according to the settings reference. At 8 bytes per value that is about 511 KiB per UInt64 column, small enough to stay close to the core’s caches.
• In the pipeline, processors such as FilterTransform, ExpressionTransform and AggregatingTransform consume and produce chunks. The pipeline is replicated across max_threads streams and partial aggregation states are merged at the end.

Only the columns a query references are read and decompressed. That is the storage half of the story, and it is covered with measurements in the column pruning section.

Code generation

LLVM JIT on top of vectorization

ClickHouse vectorized query processing has one known cost: each function writes a temporary column that the next function reads back. For long arithmetic expressions, ClickHouse can fuse the chain into one native function with LLVM. The VLDB paper explains that compilation starts only after the same expression has been seen a configurable number of times, controlled by min_count_to_compile_expression, so short one-off queries do not pay the compile cost.

SELECT sum(((number * 7 + 3) % 1000) * 2 + (number % 13) * 5
           - (number % 11) * 3 + ((number * 17) % 97))
FROM numbers(100000000)
SETTINGS max_threads = 1,
         compile_expressions = 1,
         min_count_to_compile_expression = 0;

Compiled code is cached, so the compile cost is paid once per expression shape rather than once per query, and the cache can be inspected and dropped like any other ClickHouse cache. Where compilation fails or is not supported for a function, the engine silently falls back to the regular vectorized path, which makes the setting safe to leave enabled.

Both runs return the same result. The gain depends on how long the expression chain is: simple aggregates barely change, while wide arithmetic and conditional expressions benefit most.

Honest limits

Where ClickHouse vectorized query processing stops helping

ClickHouse vectorized query processing removes interpretation overhead and feeds SIMD units. It does not remove every cost, and knowing the boundaries saves a lot of tuning time.

• Point lookups and tiny queries. A query that returns a handful of rows spends most of its time parsing, planning and locating granules. Block size barely matters there; the primary key and sort order decide the latency.
• Random memory access. Hash aggregation and hash joins probe tables at unpredictable addresses. ClickHouse chooses a specialised hash table per key type to soften this, but high-cardinality GROUP BY and large joins remain bound by cache misses and memory, not by SIMD width.
• Row-shaped logic. Executable UDFs, per-row string parsing and deeply nested conditionals leave less for the vector units to do. Rewriting them with built-in array and string functions usually pays back quickly.
• Merges and small parts. Thousands of tiny parts mean thousands of small reads and short vectors. Batching inserts and keeping part counts healthy is part of query performance; see monitoring merge queues in ClickHouse.
• Too many threads on too few cores. Parallel streams multiply throughput only while cores and memory bandwidth are free. On shared hosts, raising max_threads past the physical cores adds contention rather than speed.

In practice, ClickHouse vectorized query processing is rarely the bottleneck in a slow ClickHouse estate. The usual culprits are schema choices, sort keys that do not prune, and ingestion patterns. That is why every ChistaDATA engagement starts with evidence from system.query_log and system.parts rather than with settings changes.