I'm testing against SQL Server 2019 CU14. I have a pure row-mode query that selects the top 50 rows from a complicated view. The full query takes 25426 ms of CPU time at MAXDOP 1 and 19068 ms of CPU time at MAXDOP 2. I'm not surprised that the parallel query uses less CPU time overall. The parallel query is eligible for bitmap operators and the query plan is different in a few ways. However, I am surprised by a large reported difference in operator times for the top N sort.
In the serial plan, the top N sort is reported to have taken around 10 seconds of CPU time by operator execution statistics:
The MAXDOP 2 plan reports around 1.6 seconds of CPU time for the same top N sort:
I don't understand why such a large difference is reported between the two different query plans. The compute scalars in the parent operator are very simple and cannot explain the discrepancy in operator times. Here is what they look like:
[Expr1055] = Scalar Operator(CASE WHEN COLUMN_1 IS NULL THEN (0) ELSE datediff(day,COLUMN_1,getdate()) END), [Expr1074] = Scalar Operator(CASE WHEN [Expr1074] IS NULL THEN (0) ELSE [Expr1074] END)
There are other compute scalars in different parts of the plan. I uploaded anonymized actual plans for the serial plan and the parallel plan if someone wants to review them.
When I load the full query results without TOP into a temp table and perform a TOP 50 sort on the temp table, both the parallel and the serial plan take around 1200 ms of CPU time to perform the sort. So, the reported operator time for the parallel sort in the full query feels reasonable to me. The ten seconds for the serial query does not.
Why does the serial top N sort have a much higher reported CPU time than the parallel sort? Is it truly so much less efficient or could this be a bug with operation execution statistics?