Cost Threshold for Parallelism is a setting in SQL Server that’s been around for as far back in the product that I can think of. It decides how expensive an operator needs to be because SQL Server will use multiple threads for that operator instead of a single thread. The Cost Threshold for Parallelism setting is set for a default of 5 (which is a horrible setting, but we’ll get into that later) which means that any operators which have a cost of below 5 will only use a single thread and any operators will have a cost of 5 or more will use multiple threads.
SQL Server has a default of 5 because it has to have something as the default. But that setting should be changed for most systems. For OLTP systems, I typically recommend changing this setting to a value of 50. The reason that I like to start with a setting of 50 for OLTP application is that any operators that have a cost of less than 50, typically aren’t going to see any improvement by using multiple threads. They will usually get slower because of the cost of using parallelism. So we want to keep the quicker queries from using parallelism so that it’s only being used by the more expensive queries that actually need it.
Now 50 isn’t a perfect setting. After making a change to the setting, the server needs to be monitored to make sure that to many queries aren’t going parallel. The Cost Threshold for Parallelism might need to be adjusted again after the initial change, so keep in mind that this isn’t a one size fits all recommendation.
Another thing to keep in mind is that changing this setting will cause your plan cache to be expired and all the plans will need to be recompiled, so you should see CPU load on the server go up right after you change the setting.
Denny
The post Cost Threshold for Paralellism appeared first on SQL Server with Mr. Denny.
