Problem
sp_StatUpdate can use Query Store signals for pre-maintenance prioritization, but Query Store wait surfaces are not a truthful proof channel for the later UPDATE STATISTICS statement itself.
That matters for sort-spill diagnostics. A spill attributed to the generated UPDATE STATISTICS command cannot be proven from Query Store wait data alone, because the DDL statement is not represented there in a way that supports direct spill attribution.
Why this matters
If the procedure claims or implies that Query Store wait metrics prove UPDATE STATISTICS spill behavior, operators can be led to the wrong conclusion about where the memory-pressure event actually occurred.
This is especially relevant when investigating grant-capped or tempdb-heavy statistics maintenance. Preselection and proof are different jobs:
- Query Store can help choose candidates before the run
- truthfully proving the
UPDATE STATISTICS spill itself needs a different surface
Proposed fix
Add an Extended Events based proof path for UPDATE STATISTICS spill diagnostics, using:
sort_warning as the primary event surface- statement-text filtering around the generated
UPDATE STATISTICS command
- optional tempdb / wait-side supporting breadcrumbs only as secondary context
Keep Query Store for pre-maintenance ranking where appropriate, but do not present it as the proof surface for the actual stats-update spill event.
Acceptance criteria
- the procedure no longer treats Query Store wait data as proof of
UPDATE STATISTICS spill behavior
- spill attribution for the generated stats-update statement is anchored on XE, not Query Store
- operator-visible output and documentation clearly distinguish preselection signals from proof surfaces
- sort-spill diagnostics can be tied back to the generated
UPDATE STATISTICS command with a truthful evidence path
Problem
sp_StatUpdatecan use Query Store signals for pre-maintenance prioritization, but Query Store wait surfaces are not a truthful proof channel for the laterUPDATE STATISTICSstatement itself.That matters for sort-spill diagnostics. A spill attributed to the generated
UPDATE STATISTICScommand cannot be proven from Query Store wait data alone, because the DDL statement is not represented there in a way that supports direct spill attribution.Why this matters
If the procedure claims or implies that Query Store wait metrics prove
UPDATE STATISTICSspill behavior, operators can be led to the wrong conclusion about where the memory-pressure event actually occurred.This is especially relevant when investigating grant-capped or tempdb-heavy statistics maintenance. Preselection and proof are different jobs:
UPDATE STATISTICSspill itself needs a different surfaceProposed fix
Add an Extended Events based proof path for
UPDATE STATISTICSspill diagnostics, using:sort_warningas the primary event surfaceUPDATE STATISTICScommandKeep Query Store for pre-maintenance ranking where appropriate, but do not present it as the proof surface for the actual stats-update spill event.
Acceptance criteria
UPDATE STATISTICSspill behaviorUPDATE STATISTICScommand with a truthful evidence path