Summary
Statement-level wait stats from actual plans are currently only used to enrich Rule 25 (Ineffective Parallelism) and Rule 31 (Parallel Wait Bottleneck). They're displayed in the UI wait stats card but ignored by all other analyzer rules.
Wait stats can confirm or elevate warnings across many rules — they're the first thing an experienced tuner looks at, and we already have the data.
Candidate rules for wait stat integration
- Rule 1 (Filter) — I/O waits amplify filter impact
- Rule 5 (Row Estimates) — spill-related waits confirm bad estimates caused real harm
- Rule 9 (Memory Grant) — RESOURCE_SEMAPHORE confirms the grant was actually problematic
- Rule 11 (Scan with Predicate) — I/O waits + expensive scan = stronger signal for indexing
- Rule 16 (Nested Loops) — lock waits on inner side suggest contention
- New rules — e.g., "your query spent 90% of time on LCK_M_X" as a standalone finding
Context
Came up during issue #178 round 3 (Joe Obbish feedback item #22). Adding targeted PAGEIOLATCH advice to the parallelism warning was a clear win — the same approach should apply broadly.
Summary
Statement-level wait stats from actual plans are currently only used to enrich Rule 25 (Ineffective Parallelism) and Rule 31 (Parallel Wait Bottleneck). They're displayed in the UI wait stats card but ignored by all other analyzer rules.
Wait stats can confirm or elevate warnings across many rules — they're the first thing an experienced tuner looks at, and we already have the data.
Candidate rules for wait stat integration
Context
Came up during issue #178 round 3 (Joe Obbish feedback item #22). Adding targeted PAGEIOLATCH advice to the parallelism warning was a clear win — the same approach should apply broadly.