SQL Server Parallelism Operator

Hi Geeks,

Today we will talk about SQL Server Parallelism Operator. SQL Server may decide parallelism to help some expensive queries to run faster which means it decides to use multiple processors simultaneously. In order to make this happen, we should have either two processors or cores or a hyper-threaded setup and in addition affinity mask as well as max degree of parallelism must be configured appropriately.

Let us verify each of these configurations first before going into the topic.

USE master




As we see in the above figures, both of these parameters are configured to default value 0 which means they allow SQL Server to use at-least two processors.

Let me run a simple COUNT(*) statement on TransactionHistory table.

USE [AdventureWorks2012]

FROM Production.TransactionHistory


This query plan uses a single worker and is very simple. Execution plan uses Index scan followed by Stream Aggregate (read here Part1, Part2, Part3) and Compute Scalar (read here Part1, Part2) operations. As of now, there is no parallelism operations in query execution. Important point to note here is, Parallelism operation will only be considered when estimated cost of any serial plan is higher than cost threshold for parallelism value configured in sp_configure. Let’s verify configured value for this.

USE master



It is set to default value 5 seconds and for the same reason we do not see parallel execution. We will now change this value to 0 for demo purpose then run same query.

USE master

--Step 1
sp_configure 'cost threshold for parallelism',0

--Step 2

--Step 3


Above figure shows cost threshold for parallelism has been changed to 0 seconds i.e. SQL Server will create a parallel plan for any queries when elapsed time exceeds 0 seconds. We will now run the same query again;

USE [AdventureWorks2012]

FROM Production.TransactionHistory


From above figure we can observe the presence of parallelism operator. The yellow arrows identify the operations that involve multiple workers where each workers are assigned to a different part of the problem. At the end all partial results are combined then SQL Server produces final result.

Note: This is just an illustration and you should never ever try this method in your live systems.

That’s it for today, you can read all blogs in One operator a day series by clicking here and here is the Index for my execution plan series.

Happy Learning!



Like us on FaceBook | Join the fastest growing SQL Server group on FaceBook | Follow me on Twitter | Follow me on FaceBook


About Kanchan Bhattacharyya

Kanchan is an astute IT professional, a seasoned SQL Database Administrator with 13+ years of industry experience. A calculated risk taker with deep technical knowledge and has gained proficiency in database consulting and solutions across different environments. Kanchan holds MBA degree in IT and an International Executive MBA in Project Management. He is very passionate about SQL Server and holds MCSE (Data Platform), MCSA – SQL 2012, MCITP – SQL 2008 certifications. Currently he is focusing on cloud and latest releases of SQL Server. When not working, Kanchan likes to spend his time reading on new technical developments specifically on SQL Server and other related technologies.

View all posts by Kanchan Bhattacharyya →

Leave a Reply

Your email address will not be published.