When Profiling SQL Server Stored Procedures Gets Tricky

[@nezbrun872]

Yes, I totally agree, taking queries apart is a key tool in your toolbelt when analysing and figuring out solutions to non-trivial scenarios. That's a big problem with SQL, it can be, what I, as an old fart, calls "write only", when queries become several pages along, with several dozen joins and subqueries... and I've been doing SQL since 1988, SQL Server in particular since 1991. It's not at all unusual that the only practical way to figure out what the programmer intended is to take the query apart, then reconstruct it... and then test, test, test that you have the same results, with different fully representative datasets, but with results multiple orders of magnitude faster. Getting a query 10% or 100% faster in SQL isn't particularly impressive, and it sometimes shows you've not fully understood the nature of the problem. You should be looking for 10x, 100x, 1000x, 10000x+++ improvements. It's all about the IO, baby. (Oh, and CPU and blocking sometimes too). Thanks so much again for your content.

[@Lhord_Neville]

I was surprised, amused and bewildered as per usual, so thanks again for the tidbits.

[@Lhord_Neville]

PS I learnt something

[@ErikDarlingData]

Just don't forget it.

[@Chompingbits]

One month of a cable bill or half of your streaming services

[@ErikDarlingData]

Where do you get cable from?!

[@FlaggedStar]

I think I've missed the point. What about plain old Extended Events makes this difficult?

[@ErikDarlingData]

I don't know how to answer someone who has missed the point and asked a vague question.

[@jg7734]

It's me, I'm the second "Ick"

[@ErikDarlingData]

Hello, Ick.