- You have a table that has clustered columnstore indexes on it, and the table has lots of columns (in hundreds).
- The data (data type) of these columns is highly compressible data such as varchar.
- You run a SELECT statement against this table to select a large subset or all columns from this table.
- Your select statement has a WHERE clause that limits the output of it to a very few rows (the query is highly selective).
- The concurrent workload, (other queries that are executed at the same time on the server as this query), may encounter decrease in performance and loss of throughput.
- You may see intermittent high CPU usage.
- If you query sys.dm_os_ring_buffers and view SchedulerMonitor type entries, you find intermittent "non-yielding scheduler" messages logged during the time of execution of this query.
- You may receive a non-yielding scheduler error in error log and a symptom memory dump file may be generated.
Fix detailsThe workers that process the column segments (uncompressing them and scanning them for qualifying rows) used to "yield" CPU usage to other workers/concurrent query executions when a certain threshold number of rows was output. When the WHERE clause was highly selective to produce few rows, the workers that process this query processed uncompressed and large number of segments (because very few rows qualify) before they gave up the CPU in cooperative manner for other workers to process their workload. This led to irregular CPU usage and throughput degradation for concurrent workload. The fix optimizes and improves CPU sharing algorithm for such columnstore queries.
Article ID: 3191487 - Last Review: Oct 18, 2016 - Revision: 1