As mentioned earlier, Query Store uses CPU time as the main criterion for execution plan comparison. Execution time often differs from CPU time, sometimes very significantly. In production environments, thousands or even hundreds of thousands of queries are running simultaneously and since most of them refer to the same database objects and SQL Server resources are limited, a query is usually not executed at once; during the execution, there are phases where instructions in the query are executed, and phases where the query waits for resources to be available to proceed with the execution. What a query is waiting for is very important information in performance troubleshooting. Unfortunately, waits were not captured by Query Store in SQL Server 2016, but SQL Server 2017 removes this limitation and increased captured data with this important information.

Since there are more than 900 wait types, in order to reduce Query Store’s impact on customer workload and to simplify recommended tuning actions, Query Store groups wait types into wait categories. Different wait types similar by nature are combined in the same category. The following table shows how common wait types are mapped into wait categories:

You can find the complete mapping table at: https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-query-Query Store-wait-stats-transact-sql.