In last week’s Query Plans Pop Quiz, the first question was, someone hands you these two queries and you get their estimated plans to decide which query to tune. Perhaps you get the estimated plans from SSMS, or from sp_BlitzCache, or from your monitoring tool.

The question was, which query should you focus on tuning? A disturbing number of comments pointed at the top query, saying that it had 100% of the cost, and that its sort was 99% of that giant cost. Wrong-o. Not even close. Do not pass go, do not collect $200.

The right answer: ignore
“query cost relative to the batch.”

Estimated query plans are like a project manager’s guess of what’s going to happen when we execute the project. It’s all candy and unicorns through rose-colored glasses.

To show you what I mean, let’s rerun these queries and get their actual plans instead of their estimates:

Focus on the times closest to the SELECT operators:

On some queries, those times can be deceiving, but not these particular queries. The first query finished in less than 3 seconds, but the second query took over a minute to execute. Armed with that time information, which query do you wanna tune? The answer’s clearly the second query, right?

Yet look at their costs relative to the batch again, which is probably the part you focused on when thinking about which query to tune:

Query 1’s sort of 99% cost? It didn’t even sort a single row! Literally no work was done in that step whatsoever. The 100% query cost was meaningless, as was the 99% sort cost. Totally and utterly meaningless.

Even on actual plans,
those costs are meaningless garbage.

The “Query cost (relative to the batch)” numbers are junk. Seriously, set them on fire, then burn their ashes. They’re worthless, and they distract you from the real problems. I wish Microsoft wouldn’t even show them on actual plans because they mislead people so badly.

Imagine going to a project manager halfway through a project and asking them, “Hey, why’s the project running late and over budget?”

And imagine if the project manager turned to their initial plans for the project, looked them over, and said happily, “Well, according to my estimates, we’re right on track!”

That’s what “Query cost (relative to the batch)” is – it’s all based on estimates made before the query even started. When those estimates go wrong and queries perform poorly, the project manager is still there giving an all-thumbs-up, happily reporting their original status goals.

The costs are the problem,
not the estimated plan.

If you’re just getting started query tuning, your best bet by far is to focus on the longest-running queries, and then grab my Fundamentals classes during my upcoming Black Friday sale to start leveling up. The more advanced folks in the audience, like the ones who’ve conquered my Mastering Query Tuning class, will be able to spot the real problem areas in plans, whether the plans are estimated or actual.

But everybody in the audience – junior or senior – should simply ignore the “Query cost (relative to the batch)” numbers lest they waste time tuning queries that aren’t even a problem to begin with.

Stay tuned for next week and we’ll discuss questions 2 & 3 from the quiz – and it’s a mixture of good news, bad news. A lot of you got question 2 right, but a disturbing number of y’all failed question 3.