QDS_STMT is recorded when a thread waits for access to Query Store’s map of query hashes, the structure that tracks which queries have been seen. Registering a previously-untracked query requires latching that map exclusively to add the new hash, so every genuinely new query text pays a brief serialisation.
For workloads that parameterise well, new hashes are rare and the map stays quiet.
Is It a Problem?
It can be, in one specific shape: a very busy ad hoc workload, where nearly every statement has unique text (unparameterised literals), turns “register a new query” into a hot path, and this wait becomes prevalent. That is Query Store amplifying an ad hoc problem your plan cache already suffers from.
The documented mitigation is QUERY_CAPTURE_MODE = AUTO, which skips capturing ad hoc one-offs instead of registering every unique text; it typically resolves the bottleneck while keeping the queries that matter.
Common Causes
- High-rate ad hoc workloads generating endless unique query texts.
QUERY_CAPTURE_MODE = ALLon such workloads, forcing every text into the map.- Deployment or cache-flush events making many queries “new” at once (transient).
What To Do
- Set
QUERY_CAPTURE_MODE = AUTOon the affected databases (the default from SQL Server 2019); confirm withsys.database_query_store_options. - Attack the root: parameterise the application’s hot statements, or use forced parameterization for a targeted database.
- Watch the plan cache stats too; the same ad hoc churn bloats it in parallel.
How To See It
Rank it against everything else with Get-WaitStatistics; prevalence points straight at capture mode and ad hoc query volume.
Part of the SQL Server Wait Types Library.
Related deep dive: RESOURCE_SEMAPHORE Wait Type.
Leave a Reply