@AndriyM Maybe but not necessarily. I tend to be pretty strict about these things.
So when using APPLY for that I usually see a nested loop join. Previously I would have described it as a trivial join that didn't really mean much in terms of overall performance.
But what if you're using CCIs in the query? Nested loop joins can't be implemented in batch mode. You end up with adapters that change the query execution from batch mode to row mode (and possibly back).
Also the work that you're doing in the APPLY statement will be done in row mode, I think
Paul has said that switches from batch to row mode can have big performance consequences in some queries. I haven't observed that myself yet, but I don't like taking any chances when I can help it.
So APPLY for that purpose is no longer in my bag of tricks :(
Some queries will experience performance benefits even without proper CCIs. But you need to hack in it. But yeah, if not using CCIs no need to be concerned.
Well, other than the occasional developer-unfriendliness of query execution performance, but that's not news to anyone.
Shouldn't the last step be ALTER TABLE [TableName] WITH CHECK CHECK CONSTRAINT ALL;? Anyway, the approach does look potentially dangerous. I wouldn't try it in a highly concurrent system.
@JoeObbish Depends how you write it. If the SQL is a simple project it is always OK in my experience. CROSS APPLY syntax is very useful to simplify a query with many repetitions, deeply nested expressions, etc. Unnested apply is done during simplification, before trivial plan even, and it doesn't have limits, so successful unnesting should have no impact on the final plan quality.
I was inserting two data sets, using minimum logging, into an empty heap table using two:
INSERT INTO Table (TBALOCK) SELECT FROM ...
Script in Parallel (two execute SQL task running at the same time in a container). After the job hangs a bit, one of SQL tasks becomes a deadlock victim. Below ...