Consider the queries below. The only difference is 1000 vs 2000 rows returned.
SELECT TOP 1000 lwa.Message INTO #foo
FROM dbo.LogWidgetsAPI lwa (NOLOCK)
ORDER BY lwa.TimeStamp
vs
SELECT TOP 2000 lwa.Message INTO #foo
FROM dbo.LogWidgetsAPI lwa (NOLOCK)
ORDER BY lwa.TimeStamp
However, 1000 rows are returned in under a second, while the query with 2000 rows takes significantly longer.
The query plan for the first query is reasonably simple:
but the 2nd query is using parallelization:
What would using just 1k rows more force parallelization?
P.S. The table contains over 6 million records and TimeStamp column is indexed.
Estimated Subtree Cost
is 6.63. For query with 2000 rows, it's 9.03. TheCost Threshold for Parallelism
is 12 andMax Degree of Parallelism
is 4.OPTION (MAXDOP 1)
to the end of your second query, and see what your timing looks like. When you get right down to it, there are many things that can slow down a query with more rows, from insufficient free memory to insufficient free CPUs to cover your parallelism.