The top-CPU drill-down resolves statement text for the five queries it prints, not every plan-cache row in the window (#3959)

[erikdarlingdata]

Closes #3959.

Why

The top-CPU drill-down (behind CPU_SQL_PERCENT and CPU_SPIKE findings) projected query_text inside its window. On Darling, v_query_stats resolves that column with a LEFT JOIN to query_text_dim, the fleet-wide text dimension. The read therefore looked up text for every plan-cache row in the analysis window and carried it through the ROW_NUMBER sort, all to print LEFT(MAX(query_text), 500) for five groups. This is the pattern #3956 removed from the parameter-sensitivity drill-down. I filed it separately there because this read is pinned byte-identical to Lite's (#3648), and its MAX(query_text) output needs care to keep identical.

The frozen Dashboard's twin did the same with MAX() over every window row's compressed varbinary(max) statement.

What changes

• Darling and Lite (one SQL text, byte-identical per the Top Cpu Queries' Max Dop is a cross-plan cumulative maximum with no provenance: it said 16 on a MAXDOP-1 instance whose stored plan is serial, and drove a wrong tuning recommendation #3648 pin).
  • The window and the ranking no longer project query_text.
  • A top_queries CTE ranks and cuts to five exactly as before.
  • The final SELECT reads LEFT(MAX(query_text), 500) for each printed group, over the same rows the single pass aggregated: that group's window rows under the window's own filter (server, time bounds, delta_worker_time > 0).
  • It matches with equality first, which the (server_id, query_hash, collection_time) index serves.
  • GROUP BY puts NULL keys in one group that equality cannot match. A CASE therefore sends a group with a NULL database_name or query_hash to an IS NOT DISTINCT FROM read, and only such a group; PostgreSQL never runs that branch otherwise.
• The frozen Dashboard. Its SELECT TOP 5 ... MAX(query_text) becomes:
  • a TOP (5) CTE without text;
  • an OUTER APPLY that takes the same MAX(qs.query_text) per printed group, then DECOMPRESS;
  • a hash match made NULL-safe as (qs.query_hash = t.query_hash OR (qs.query_hash IS NULL AND t.query_hash IS NULL)), because IS NOT DISTINCT FROM needs SQL Server 2022. database_name is NOT NULL there.
• Output is unchanged in all three SKUs: same rows, same columns, same order, same text. The one caveat is ties at the cut: when two groups have exactly equal total_cpu_us, which one makes the top five was arbitrary before and still is.
• Test plumbing. The EXPLAIN join-probe counter The plan-regression drill-down reads only the fact's offenders instead of re-deduplicating the whole Query Store slice, and the PSP drill-down resolves text for its printed rows only (#3902) #3956's PSP test used is now the shared ExplainJoinProbe, so both drill-down text tests count the same way.

Test plan

Measured before and after, same data, interleaved:

read	before	after
Darling, rig (PG 18.4 / TSDB 2.28.1, C collation, 400K-text query_text_dim, 72K-row query_stats window, work_mem 31MB), median of 5	260.6 ms (259-270)	132.2 ms (118-137)
Lite, DuckDB 1.4.4 (Lite-shaped query_stats, 72K rows of ~1.2 KB inline text), median of 3	156 ms	149 ms
Dashboard, SQL Server 2016 scratch database (72K rows of ~1.2 KB compressed text, the install's IX_query_stats_hash_lookup), warm	1,140-1,360 ms	32-47 ms
Darling, DARLING01 real data (SQL2025, SQL2022: about 1K CPU rows per window)	7.9-8.8 / 6.1-6.6 ms	8.5-8.9 / 7.2-7.8 ms

At DARLING01's size the extra subqueries cost about 1 ms. The win arrives with the production-sized window, where the old read resolved and sorted text for every row.

• Identity, oracle = the old SQL verbatim, every column of every row. The seed is built to break a restriction that is almost right:
  • three of the five printed groups have a NULL key (NULL database, NULL hash, both NULL);
  • a group's winning text is the inline legacy text beside a digest;
  • a digest has no dimension row;
  • a text runs past the 500 cut;
  • trap rows carry a text that would win MAX but lie outside the read's own filter: zero CPU, before the window, another server.
  • Tests: TopCpuQueriesTextLiveTests (Darling, live), TopCpuQueriesTextTests (Lite, DuckDB). Both also pin each text case by value.
• Identity, md5 over the full ordered output: the rig (5 rows) and DARLING01's SQL2025 and SQL2022 (5 rows each, read-only) match.
• Dashboard identity: old and new side by side on a scratch database on SQL Server 2016 (compatibility level 130; dropped afterward). Identical rows on the 72K-row set, and on a set with two NULL-hash groups (different databases) at the top of the ranking.
• Read shape (Darling, live): the plan resolves text for 20 rows, the printed groups' rows. The old shape resolves 140, every window row, and serves as the positive control.
• Shape pins, ungated: TopCpuQueriesTextShapeTests (Darling), the shape fact in TopCpuQueriesTextTests (Lite, Lite's inline text), and TopCpuQueriesTextMirrorTests (Dashboard.Tests, source idiom). The Top Cpu Queries' Max Dop is a cross-plan cumulative maximum with no provenance: it said 16 on a MAXDOP-1 instance whose stored plan is serial, and drove a wrong tuning recommendation #3648 byte-identity pin (DrillDownDopProvenanceParityTests) passes unchanged.
• Checked red:
  • Each pin fails against the old sources.
  • The Darling live test fails on the old SQL: "resolved text for 140 row(s) to print 5 groups of 4".
  • Two mutations fail the identity assertions in Darling, and the first also in Lite:
    • with the NULL-safe branch disabled, a NULL-key group prints "";
    • with the text read's CPU filter dropped, the trap text wins.
• Full Darling.Tests with DARLING_TEST_PG: 12,702 total, 0 failed, 24 skipped (the runtime-gated tests).
• Full Lite.Tests: 5,134 total, 0 failed.
• Full Dashboard.Tests: 817 total, 0 failed.

🤖 Generated with Claude Code

https://claude.ai/code/session_018Z4T51J4E6L8fjriPHpsif