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.
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!