Parallelism in queries

A query is more likely to use parallelism if the query processes a lot more rows than are returned. In this case, the number
of rows processed includes the size of all rows scanned plus the size of all intermediate results. It does not include rows
that are never scanned because an index is used to skip most of the table. An ideal case is a single-row GROUP BY over a large
table, which scans many rows and returns only one. Multi-group queries are also candidates if the size of the groups is large.
Any predicate or join condition that drops a lot of rows is also a good candidate for parallel processing.

Following is a list of circumstances in which a query can not take advantage of parallelism, either at optimization or execution
time:

the server computer does not have multiple processors

the server computer is not licensed to use multiple processors. You can check this by looking at the NumLogicalProcessorsUsed
server property. However, note that hyperthreaded processors are not counted for intra-query parallelism so you must divide
the value of NumLogicalProcessorsUsed by two if the computer is hyperthreaded.

the max_query_tasks option is set to 1

the priority option is set to background

the statement containing the query is not a SELECT statement

the value of ActiveReq has been greater than, or equal to, the value of NumLogicalProcessorsUsed at any time in the recent
past (divide the number of processors by two if the computer is hyperthreaded)