Browser History
I’ve blogged about OUTPUT a couple times, and those posts are Still Accurate™
But it’s worth noting that, for the second post OUTPUT forced the query to run serially with no target; just returning data back to SSMS.
Depending on the query behind the putting of the out, parallelism could be quite important.
That’s why in the first post, the put out into a real table didn’t cause performance to suffer.
Of course, if you OUTPUT into a table variable, you still have to deal with table variables being crappy about modifications.
Samesies
If you compare the performance of queries that output into a @table variable vs one that outputs into a #temp table, you’ll see a difference:
Even though the parallel zone is limited here, there’s a big difference in overall query time. Scanning the Votes table singe-threaded vs. in parallel.
When you’re designing processes to be as efficient as possible, paying attention to details like this can make a big difference.
Thanks for reading!
Going Further
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. I’m offering a 75% discount to my blog readers if you click from here. I’m also available for consulting if you just don’t have time for that and need to solve performance problems quickly.
Related Posts
- Common Table Expressions Are Useful For Rewriting Scalar Functions In SQL Server
- Multiple Distinct Aggregates: Still Harm Performance Without Batch Mode In SQL Server
- What’s Really Different About In-Memory Table Variables In SQL Server?
- When Index Sort Direction Matters For Query Performance In SQL Server