A LIKE query against ten million rows used 37.6MB of peak memory on ClickHouse 26.9. The same table, the same query, same hardware, on 26.10 released six days ago: 1.48MB. Nothing else about the query changed.

ClickHouse 26.10 shipped on 6 November 2026 with a new setting, apply_string_filters_during_scan , on by default. It pushes substring search conditions down into the column scan itself, so rows that don't match never get fully materialised. I wanted to know what that's actually worth, where it stops working, and what a reader would hit if they relied on it without reading the fine print.

What the setting does

The description in system.settings is unusually precise for a ClickHouse setting:

When a PREWHERE condition contains a conjunct that searches for a non-empty substring in a String column (LIKE, position, startsWith, endsWith, or equality with a non-empty string), the reader checks every value against this condition during deserialization and reads non-matching values as empty strings.

Enter…