QDS_PERSIST_TASK_MAIN_LOOP_SLEEP is recorded by the Query Store background persistence task while it sleeps between rounds of flushing captured query metrics from memory to disk. Query Store collects runtime stats in memory and writes them out on an interval (the DATA_FLUSH_INTERVAL_SECONDS setting, 15 minutes by default); this wait is the timer between those flushes.
A background writer sleeping on its schedule, nothing more.
Is It a Problem?
No. On any instance with Query Store enabled, this wait accumulates constantly and can look large in raw wait output simply because the persistence loop exists for every Query Store-enabled database, around the clock. It says nothing about Query Store health, capture overhead, or storage performance.
Genuine Query Store trouble looks different: QDS_* waits other than the sleep variants climbing, Query Store switching itself to READ_ONLY, or its size cap filling. None of those diagnose through this wait.
Common Causes
- Query Store enabled, which is the default on new databases from SQL Server 2022 and standard practice long before that.
- Multiple databases with Query Store, each running its own persistence loop.
- Long uptime compounding the sleep intervals into big totals.
What To Do
- Filter it out of wait analysis with the other timer-based background waits; our
Get-WaitStatisticsscript already does. - For actual Query Store health, check
sys.database_query_store_optionsper database:actual_statevsdesired_state, and current size vsmax_storage_size_mb(our Query Store status script covers this). - Leave the flush interval alone unless you have a measured reason; shortening it buys more frequent persistence at more background I/O for no analytical gain.
How To See It
Rank waits with Get-WaitStatistics, where this one is filtered as noise. Seeing it in raw output just confirms Query Store is on.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply