[FEATURE] In the top SELECT’s warning pop-up, link every message to its origin.

[pgfiore]

Which component(s) does this affect?

• Desktop App
• CLI Tool
• SSMS Extension
• Plan Analysis Rules
• Documentation

Problem Statement

And since the more you get the more you want, I’m here again for a (hopefully) tiny suggestion.
In the top SELECT’s warning pop-up, link every message to the right place where it is generated (when possible, of course).

Proposed Solution

If the plan is huge and the warning origin is murky, it would help to click a warning and be beamed up to a specific step.

Use Case

Alternatives Considered

No response

[erikdarlingdata]

Good request, and "the more you get the more you want" is the correct attitude to have about a tool you're using in anger. Keep them coming.

This is worth doing and it splits cleanly in two, which is worth saying because half of it is nearly free and half of it isn't.

The warnings attached to an operator already know where they came from. They hang off the node itself, and the JSON output has carried a node_id for them all along. The canvas already has the selection machinery — clicking a node highlights it — so wiring "click the warning, select that node" is mostly a reverse lookup from node to its drawn border plus a scroll-into-view. That's the easy half.

The ones in the pop-up you screenshotted are the harder half. Those are statement-level warnings, and a PlanWarning currently records type, severity, message, severity source, benefit and fix — and nothing about which operator produced it. The rule that raised it knew, at the moment it raised it; that context is simply thrown away before the warning reaches the panel. So for those, the fix isn't in the UI at all, it's carrying an origin node through from the rule that emitted it.

Which is the real work, and it's the interesting kind: some statement-level warnings genuinely have one origin operator, some have several (a plan with four spills), and a few honestly have none — "high compile CPU" isn't attributable to an operator, it happened before any operator ran. So the field wants to be a list, and the UI wants to do nothing when it's empty rather than beam you somewhere arbitrary. Linking a warning to the wrong operator would be worse than not linking it, because you'd trust it.

Related, and it's why your #436 report keeps paying off: warnings now record whether SQL Server raised them or Performance Studio inferred them. The engine's own warnings carry their operator in the plan XML, so those are the ones that can be linked most reliably.

No promises on timing, but this is going on the list in that shape: origin nodes on the warning model first, navigation second.

[erikdarlingdata]

Built and merged in #446. It will go out in the next release — no date yet, since nothing is blocked on it.

Both halves are in. Warnings now record which operator they came from, so the ones that can be linked are, and the pop-up entries you screenshotted navigate when there is somewhere honest to navigate to.

The part I want to flag, because it is a judgement I made rather than what you literally asked for. Your motivation was the plan being huge and the origin murky — but most of the messages in that particular pop-up are statement-level, and genuinely have no operator behind them. High Compile CPU happened before a single row was read; SQL Server reports UDF Execution at the statement level only. Linking those would have meant sending you somewhere arbitrary, and a wrong link is worse than no link because you would believe it. So those deliberately have no arrow.

The warnings that do have origins are the ones hanging off operators — and until now the only way to see one was to have already clicked the operator carrying it, which is no help when you do not know which operator to click. That is the actual shape of your problem. So the statement panel also gained an Operator Warnings section that indexes every warning in the plan, each one a link to its operator. Sorted by benefit, collapsed by default so it does not bury the statement's own details on a big plan.

Table variable warnings name every operator that touched one rather than picking a favourite, and where a finding has several origins the tooltip lists them all.

Second good catch in two issues. Keep going.

[pgfiore]

You know, we just have to put up with things like "High Compile CPU"... I can definitely picture heaven as a place without SQL Server! And thanks for all the fish

[erikdarlingdata]

Heaven probably still has a scalar UDF in the WHERE clause. Somebody always brings one.

Although — High Compile CPU is more actionable than it looks, and it is worth not filing it under "things we put up with". A second of CPU burned before a single row is read almost always means the optimizer was handed more than it can reason about in one pass: a deep view stack, a large join graph, an OR chain that expands badly. Splitting the query into steps with #temp tables tends to collapse it, because you are then handing the optimizer several small problems with real cardinality behind them instead of one enormous one it has to guess its way through. That is why the warning says what it says rather than just reporting the number at you.

Which is also why it has no operator to link to. It is not that we lost the information — the cost was paid before any operator existed.

Leaving this open until the release ships, then I will close it out. Two reports in two days, both of which found real defects rather than misunderstandings, and one of which turned out to be a wrong answer the tool had been giving confidently for a long time. That is a better hit rate than most.

So long, and thanks for the plans.

[erikdarlingdata]

Shipped in v1.21.0.

Warnings now link to the operator that produced them, and the statement panel has an Operator Warnings index over the whole plan — which is the part that actually answers your "the plan is huge and the origin is murky", since those were the warnings you could previously only reach by already having clicked the operator carrying them.

The ones with no honest operator behind them still have no arrow, on purpose. That is the design, not a gap.

Two reports, two releases, both of which found real defects. Thanks for the towel.