What’s the issue?
The cost threshold for parallelism is an instance level setting that controls when SQL Server considers using a parallel execution plan instead of a serial one. When the optimizer estimates a query’s cost is above this threshold, SQL Server may distribute the work across multiple CPU cores. The default value is 5, which was set in the SQL Server 7.0 era based on hardware that bears no resemblance to modern servers. On today’s systems, this value is widely considered far too low.
Why is this a problem?
With the threshold set to 5, even trivial queries become eligible for parallelism, which is rarely beneficial. Coordinating parallel execution across cores adds overhead, and for small queries this overhead often exceeds any gain from parallel processing. The result is excessive CPU consumption, increased context switching, and elevated CXPACKET and CXCONSUMER waits as workers synchronize unnecessarily.
On busy OLTP systems, a low cost threshold can cause noticeable performance degradation and crowd out larger queries that genuinely benefit from parallelism. Symptoms commonly include high CPU utilization with no clear cause, query plans that go parallel for no apparent reason, and wait statistics dominated by parallelism related waits.
What should you do about this?
Check the current value with EXEC sp_configure ‘cost threshold for parallelism’;. The widely accepted starting point is 50, though many environments tune higher based on workload. Change the value using EXEC sp_configure ‘cost threshold for parallelism’, 50; RECONFIGURE;. The change takes effect immediately and does not require a service restart.
After adjusting, monitor query performance, CPU utilization, and parallelism related wait statistics to confirm the new value is appropriate, and tune further if needed. This setting works in conjunction with max degree of parallelism (MAXDOP), so review them together when investigating parallelism issues.