This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(108.80000000000001, 66%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
select * from yieldtransit
cost threshold for parallelism run_value = 1
max degree of parallelism run_value = 0
StatementSubTreeCost = 42.1767
There is no JOIN, no WHERE, only a query as full table scan.
What for parallelism on what do you expect?
If it would be a partioned table, then maybe.
I don't have a deep understanding of Logic and Physical Operator, so I naively thought it would have a Parallel scan.
I consulted a friend who said it was due to the mechanism of parallelism that caused not parallelism, but he didn't explain much about the mechanism, so I still don't quite understand why. This article is a bit obscure and difficult for me to understand https://learn.microsoft.com/en-us/archive/blogs/craigfr/the-parallelism-operator-aka-exchange
So I would like to come here to ask everyone for advice. If there are any more user-friendly articles, please share them. Thank you very much
The final operator cannot have parallelism. There is not much point in having a parallel scan and a Gather Streams operator. Also, the major part of the execution time in this case is receiving the data in the client.
But if you try something like
SELECT col, COUNT(*)
FROM yieldtransit
GROUP BY col
This is query is likely to have parallelism, since there is now more work to do.
The final operator cannot have parallelism.
I don't know whether my understanding is correct or not. I feel that what you mean by "final operator" is "select" operators, and I agree with you very much, because I have not observed its parallelism in any scenario.
There is not much point in having a parallel scan and a Gather Streams operator.
You hit the nail on the head, that's exactly what I was wondering about in the beginning. I don't quite understand why. In common sense, when faced with a large amount of work, the more people involved, the faster it gets done. I considered the CBO model and guessed that when you said "There is not much point," you were expressing the fact that the cost of the parallel execution plan would always be greater than the serial execution plan.
I understand the example you gave below, and I discovered the same issue when testing earlier. This has left me unsure of how to summarize the phenomenon, such as how to define the "work" in "more work to do."