Query Specific Wait Statistics helped explain a sudden customer-query slowdown. The remaining workload ran normally, and recompilation had not helped.

The database was about 1.5 TB, with more than 512 GB RAM on the server. The query still showed a memory-related constraint.
We examined a recently enabled Resource Governor configuration. Temporarily disabling it restored query performance in this investigation. We then re-enabled Resource Governor with revised limits and validated the workload.
- On a supported engine and SSMS build, enable Include Actual Execution Plan for a controlled execution.
- Open the returned plan and select its root statement operator.
- Open Properties and inspect WaitStats when the runtime plan contains it.
- Correlate the wait names and times with grants, the plan, concurrent activity and workload-group limits.


Query-specific waits differ from cumulative instance totals. Their availability depends on engine version and plan content. Large physical RAM does not guarantee a query receives its requested grant.
This case does not justify broadly disabling Resource Governor. Inspect classification and resource limits. Make a targeted correction and validate its effect.
Related reading
- Comprehensive Database Performance Health Check
- SQL SERVER – Enable or Disable Resource Governor
- SQL SERVER – Turning On Graphical Execution Plan After Enabling ShowPlan Text
A measured query wait is not an instance-wide diagnosis, it is execution evidence to connect with configuration and workload.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
Discover more from SQL Authority with Pinal Dave
Subscribe to get the latest posts sent to your email.




