Better query condition cache coverage for ORDER BY ... LIMIT k queries

[shankar-iyer]

This PR makes two improvements to how the query condition cache (QCC) interacts with the TopK dynamic filtering optimization for ORDER BY ... LIMIT k queries.

1. Enable query condition cache for ORDER BY ... LIMIT n queries #104478 enabled the QCC for queries that go through TopK dynamic filtering, but it did not handle queries that are also rewritten by lazy materialization — the QCC entry was never populated in that case. Lazy materialization replaces the FilterStep that carried the QCC key, so this PR re-runs the updateQueryConditionCache pass after lazy materialization to re-attach the key to the surviving FilterStep.

2. A query selected for TopK dynamic filtering can now reuse QCC entries written by a non-TopK query that had the same predicate. The TopK query's WHERE condition is and(__topKFilter(...), <predicate>); it now also probes the cache under the bare <predicate> hash, so entries written by a plain SELECT ... WHERE <predicate> are reused. The TopK query still writes its own entries under a key salted with the TopK plan parameters, so a plain query (or a TopK query with a different LIMIT / sort key) never reads a TopK-salted entry.

Related: #104478

Changelog category

• Improvement

Changelog entry

• Queries accelerated by TopK dynamic filtering (ORDER BY ... LIMIT k) now make fuller use of the query condition cache: the cache is populated even when lazy materialization is applied to the query, and such queries can reuse entries previously written by an ordinary query that had the same WHERE predicate.
  ...

Version info

• Merged into: 26.7.1.1131 (included in 26.7 and later)

[clickhouse-gh]

Workflow [PR], commit [8137b02]

Summary: ✅

• Performance Comparison: Performance dashboard

---

AI Review

Summary

This PR reattaches query-condition-cache keys after lazy materialization rewrites the surviving storage FilterStep, and lets TopK-filtered ORDER BY ... LIMIT k reads reuse plain-predicate query-condition-cache entries while keeping TopK-salted writes isolated from ordinary queries. I re-read the current diff and prior review discussion, and I did not find any remaining correctness, safety, or regression-test issues in the current code.

Final Verdict

✅ No blocking findings.

[shankar-iyer]

Waiting for perf run with ClickBench.

[clickhouse-gh]

📊 Cloud Performance Report

🟢 AI verdict: improvement — 1 query(s) improved out of 37 analysed

This PR fixes query-condition-cache population and reuse for TopK dynamic filtering plus lazy materialization (WHERE + ORDER BY LIMIT reads). Only clickbench Q23 shows a work-backed win: CPU fell from ~1545 to ~504 ms alongside a ×2.2 faster wall time, consistent with the fixed granule-skip path. Q4, Q15 and Q31 improved in wall time only, with flat or rising CPU and no selective WHERE/TopK to exercise the change, so they were kept as no change or downgraded to not sure as co-location/cache variance. The envelope suppression on Q4 looks correct.

clickbench

🟢 1 improved · ⚠️ 2 inconclusive

Flagged queries (3 of 43)

	Query	Verdict	Baseline median (ms)	PR median (ms)	Change	q-value	Hint
🟢	23	improvement	164	73	×2.2 faster	<0.0001	cache: This WHERE + ORDER BY LIMIT read is exactly the TopK/lazy-materialization path the PR fixes; CPU work fell from ~1545 to ~504 ms, so ×2.2 faster is real and work-backed.
⚠️	15	not_sure	243	188	-22.6%	<0.0001	aggregation: Aggregation with no selective WHERE, so the QCC/TopK fix can't apply; total CPU is flat (2613 vs 2614 ms) while wall dropped, pointing to co-location cache variance.
⚠️	31	not_sure	364	325	-10.6%	<0.0001	aggregation: Aggregation with no selective WHERE, outside the QCC granule-skip path; CPU rose (3539 to 3639 ms) while wall fell, so the wall gain is co-location variance, not the PR.

_{Change = percent below ×2; the ratio of medians (×N faster/slower) beyond, where percent understates the scale. q-value = BH-FDR adjusted p; smaller is stronger evidence. MIRAI flags a query when q < fdr_q (default 0.10) — the value the verdict is based on.}

tpch_adapted_1_official

🟢 No significant changes

Debug info

• StressHouse run: d61a5ede-2aed-454a-906c-da3829b8597e
• MIRAI run: ee4c50b1-182e-443f-b536-2948093afd3f
• PR check IDs:
  • clickbench_718772_1784195137
  • clickbench_718785_1784195137
  • clickbench_718791_1784195137
  • tpch_adapted_1_official_718797_1784195137
  • tpch_adapted_1_official_718803_1784195137
  • tpch_adapted_1_official_718810_1784195137

[shankar-iyer]

📊 Cloud Performance Report

🟢 AI verdict: improvement — 1 query(s) improved out of 37 analysed

This PR fixes query-condition-cache population and reuse for TopK dynamic filtering plus lazy materialization (WHERE + ORDER BY LIMIT reads). Only clickbench Q23 shows a work-backed win: CPU fell from ~1545 to ~504 ms alongside a ×2.2 faster wall time, consistent with the fixed granule-skip path. Q4, Q15 and Q31 improved in wall time only, with flat or rising CPU and no selective WHERE/TopK to exercise the change, so they were kept as no change or downgraded to not sure as co-location/cache variance. The envelope suppression on Q4 looks correct.

clickbench

🟢 1 improved · ⚠️ 2 inconclusive

Flagged queries (3 of 43)
Query Verdict Baseline median (ms) PR median (ms) Change q-value Hint
🟢 23 improvement 164 73 ×2.2 faster <0.0001 cache: This WHERE + ORDER BY LIMIT read is exactly the TopK/lazy-materialization path the PR fixes; CPU work fell from ~1545 to ~504 ms, so ×2.2 faster is real and work-backed.
⚠️ 15 not_sure 243 188 -22.6% <0.0001 aggregation: Aggregation with no selective WHERE, so the QCC/TopK fix can't apply; total CPU is flat (2613 vs 2614 ms) while wall dropped, pointing to co-location cache variance.
⚠️ 31 not_sure 364 325 -10.6% <0.0001 aggregation: Aggregation with no selective WHERE, outside the QCC granule-skip path; CPU rose (3539 to 3639 ms) while wall fell, so the wall gain is co-location variance, not the PR.
Change = percent below ×2; the ratio of medians (×N faster/slower) beyond, where percent understates the scale. q-value = BH-FDR adjusted p; smaller is stronger evidence. MIRAI flags a query when q < fdr_q (default 0.10) — the value the verdict is based on.

tpch_adapted_1_official

🟢 No significant changes

Debug info

Q23 was the motivating factor for this PR.

[clickhouse-gh]

LLVM Coverage Report

Metric	Baseline	Current	Δ
Lines	85.90%	85.90%	+0.00%
Functions	92.70%	92.70%	+0.00%
Branches	78.10%	78.00%	-0.10%

Changed lines: Changed C/C++ lines covered: 88/94 (93.62%) · Uncovered code

Full report · Diff report

[shankar-iyer]

Rerunning the failed jobs.

[shankar-iyer]

Green CI right now at commit 8137b02