Parallelism: distributing, repartitioning, and gathering rows
A serial plan performs work through one stream. A parallel plan can divide part of that work among several workers and then coordinate the rows they produce.
Parallelism operators represent the points where that organization changes. They do not execute the whole query by themselves: they distribute, repartition, or gather streams for other operators.
Workers and streams
A worker is the unit that executes a task assigned by SQL Server. The degree of parallelism, or DOP, states how many workers may participate in a parallel zone; it is not the total number of operators and does not guarantee that every worker receives the same number of rows.
A parallel zone is a plan region where several workers can process rows concurrently. Exchange operators mark how rows enter, change distribution inside, or leave that region.
Three common exchanges
One stream -- Distribute Streams --> multiple streams
Multiple -- Repartition Streams -> redistributed streams
Multiple -- Gather Streams ------> one streamThe diagram describes the number of streams, not timing or speed. Each exchange preserves row columns, but can change which worker receives each row and whether order remains available.
Distribute Streams: starting several streams
Distribute Streams receives one stream and produces several. Each row is directed to one output stream, except for specific strategies such as broadcast distribution.
Partitioning Type states the method. When it is Hash, Partition Columns contains the columns used to calculate the destination. Distribution prepares work for several consumers; inspect per-thread rows to determine whether it was balanced.
Repartition Streams: changing distribution
Repartition Streams receives several streams and assigns every row to an output stream again. It often appears when the next operator needs rows with the same key to reach the same worker.
A hash join or hash aggregate, for example, may require distribution compatible with its key. Repartitioning enables that correspondence while adding coordination and row movement.
When one key concentrates many values in one partition, one worker may receive much more work. This difference is skew. Confirm it from per-thread rows rather than from the operator alone.
Gather Streams: returning to one stream
Gather Streams consumes several streams and produces one. It commonly closes a parallel zone before the root operator returns the result.
When it must preserve order, its properties include the ordering columns and the input streams must be merged accordingly. Without that requirement, gathering does not promise result order.
Gather Streams does not mean previous work was wasted. It marks the point where partial results must be coordinated into one stream.
Recognizing a parallel zone
In the graphical plan, some operators display two small arrows over the icon when they participated in a parallel region. Properties can expose Parallel, Actual Number of Rows for All Executions, per-thread information, and the observed degree of parallelism.
Plan XML contains the same exchanges and their logical operations. When the optimizer retains a serial plan, NonParallelPlanReason can state a reason such as an edition without parallel plans, MAXDOP 1, or a query restriction.
MAXDOP sets a limit
MAXDOP limits the degree available to a query; it does not force the optimizer to choose a parallel plan. Even with MAXDOP 4, a query can remain serial when the engine does not consider a parallel alternative possible or worthwhile.
Cost threshold, edition, available processors, query constructs, and other settings participate in the decision. Changing configuration merely to obtain an icon is not evidence of improvement.
What to inspect in the plan
| Signal | Question |
|---|---|
| Exchange type | Is the stream distributed, repartitioned, or gathered? |
| Partition columns | Which key determines the destination worker? |
| Rows per thread | Is work balanced, or is there skew? |
| Order | Does the exchange preserve or lose a required sequence? |
| DOP and executions | How many workers actually participated? |
Waits add context. An exchange-related wait may represent normal coordination or imbalance; relate it to duration, CPU, per-thread rows, and repeated behavior.
What this still does not establish
A parallel plan is not automatically faster, and a serial plan is not automatically inadequate. Dividing work adds coordination and can increase total CPU while reducing elapsed time. Skew can also leave one dominant worker.
Evaluation requires a baseline, several executions, and comparable conditions. Treat MAXDOP as a workload and environment decision, not a universal correction for one query.
Next reasonable check
Continue with Execution plan warnings that require investigation to separate a visible signal from a cause that still needs testing.