SQL Server parallelism for DML operations

SQL Server supports parallelism for some of its physical operators.

DML statements, at a high level, are logical operations. In other words, you specify what you want done, not how it's done. As long as the logical operation is maintained, SQL Server is free to satisfy the statement using any set of physical operators it deems appropriate -- that applies both to DML and DDL.

SQL Server uses the cost threshold server setting to consider using parallelism for the physical operators chosen in the query plan. There's no difference as far as parallelism is concerned between DDL and DML, because as I said, SQL Server parallelizes the physical operations (i.e., an index rebuild can use the same Index Scan physical operator as a SELECT or UPDATE query could).

So, the short answer is yes, SQL Server can parallelize DML, but aside from the cost threshold setting, you have very little control over it. (That said, it can be restricted by using things like MAXDOP hints.)


Related, but a bit aside: for a query plan that includes parallel operators, the DOP at which the query runs is selected dynamically at execution time, not at plan compile time.


OK looking around I can confirm, you are right DML can be run in parallel.

Here is official confirmation taken from http://technet.microsoft.com/en-us/magazine/dd320292.aspx

Certain types of statements cannot be processed in parallel unless they contain clauses, however. For example, UPDATE, INSERT, and DELETE are not normally processed in parallel even if the related query meets the criteria. But if the UPDATE or DELETE statements contain a WHERE clause, or an INSERT statement contains a SELECT clause, WHERE and SELECT can be executed in parallel. Changes are applied serially to the database in these cases.


SQL Server 2014 support parallel DML in the form of SELECT INTO and SQL Server 2016 support parallel INSERTs into heap via INSERT SELECT providing the TABLOCK hint is used on the source table, this also works on clustered column stores, I am yet to try this out with clustered indexes though.