Fix #594: per-execution row estimates on inner-loop nodes; Fix #595: no-grant memory display

[erikdarlingdata]

What does this PR do?

Fixes three related bugs. The plan viewer and the analyzer both compare an operator's actual row count to its estimate. Each one gets that comparison wrong, in a different way.

Issue #595: the Runtime Summary showed a false 100% for a query with no memory grant.

When a statement's MemoryGrantInfo reports GrantedMemory="0", the Runtime Summary showed "0 KB granted, 0 KB used (100%)". A query with no memory grant did not use 100% of anything. The panel now shows "No memory grant", with no percentage. It uses the same neutral color as any other row that is not flagging a problem.

Issue #594: the plan viewer compared a total row count to a per-execution estimate.

EstimateRows is SQL Server's estimate for one execution. ActualRows is the total across every execution. In a parallel plan, it is the total across every thread instead. The node label, the edge color, and the minimap divided the total by the per-execution estimate, with no adjustment for either case. An operator on the inner side of a Nested Loops join runs once per outer row. A correct per-execution estimate on that operator looked like a huge misestimate.

The fix adds one function, RowEstimateHelper, in PlanViewer.Core. It multiplies the estimate by ActualExecutions, but only on the inner side of a Nested Loops join. That side is the join's second child, including a loop nested inside another loop. It also requires ActualExecutions to be greater than 0. Everywhere else, ActualExecutions counts threads in a parallel plan, not repeats, so the estimate stays at one execution.

The desktop app's node label, edge color, and minimap now call this function. The minimap needed no direct edit. It already calls the same shared GetLinkColorBrush method as the main canvas.

The Blazor web viewer's node label now calls it too, through a new linked-file entry in PlanViewer.Web.csproj. The HTML export, which the web viewer offers as a download, writes the same "N of M rows" line. It now uses the same estimate, through a new expected_rows field on each operator in the analysis result. So the CLI's JSON output carries that field too. The CLI needed no code change.

I verified this on eager_index_spool_plan.sqlplan (DOP 8, every operator parallel). Node 1, the join itself, is not on the inner side. It reads "609 of 2,983 (20%)", the same before and after this fix. Nodes 4 and 5 are both on the inner side. They now read "609 of 613 (99%)" instead of the old "609 of 1 (60,900%)".

The analyzer had the opposite bug, in rules 5, 16, and 26. Each rule divided the actual rows by ActualExecutions on every node, including a node that is not on the inner side. In a parallel plan, that number is a thread count, not a real execution count. The analyzer inflated real misestimates, and it invented some that were not there.

In the same fixture, Node 1 read as a 39x overestimate. The real number is 4.9x. These three rules now use the same RowEstimateHelper, so the viewer and the analyzer agree.

Which component(s) does this affect?

• Desktop App (PlanViewer.App)
• Core Library (PlanViewer.Core)
• CLI Tool (PlanViewer.Cli)
• SSMS Extension (PlanViewer.Ssms)
• Tests

This also affects the web viewer, PlanViewer.Web. This template has no checkbox for it.

How was this tested?

Plan files: estimated plans were not affected. The label, edge, and minimap logic all still gate on HasActualStats. I tested actual plans with the existing fixtures under tests/PlanViewer.Core.Tests/Plans, mainly eager_index_spool_plan.sqlplan (DOP 8) and memory_grant_wait_plan.sqlplan. Platform: Windows, through the headless Avalonia test session (HeadlessUi).

New tests:

• RowEstimateHelperTests covers the inner-side walk. It tests a plain node, the outer child, the inner child, a descendant of the inner child, and a loop nested inside another loop. It also covers the executions guard, the zero-estimate cases, and the exact numbers from eager_index_spool_plan.sqlplan for Nodes 1, 4, 5, and 6. It also checks the row line in the HTML export for Nodes 1 and 4.
• NodeLabelRowAccuracyTests loads eager_index_spool_plan.sqlplan into a real PlanViewerControl and reads the rendered node labels. Nodes 4 and 5 read "609 of 613 (99%)" in a neutral color, not the old "609 of 1".
• RuntimeSummaryMemoryGrantTests loads memory_grant_wait_plan.sqlplan with GrantedMemory and MaxUsedMemory patched to 0. The Memory Grant row has no percent sign and a neutral color. This fixture has a real spill elsewhere in the plan, so the color check means something. Before the fix, the spill alone painted the row as a warning, even with nothing to warn about.
• Two new gate tests in AnalyzerRuleGateTests cover rule 5. A non-inner node in a parallel zone no longer fires a false 39x-style warning. An inner-side node with a real mismatch still fires, with the per-execution phrasing. One more test covers rule 16: the outer child's message now uses the real actual rows, not the actual divided by the thread count. One more covers rule 26: a row goal that did not hold is no longer hidden by dividing by the thread count.
• A new pinned test in PlanAnalyzerTests confirms that eager_index_spool_plan.sqlplan Node 1 gets no "Row Estimate Mismatch" warning after the fix.

Golden-master diff: before I changed the analyzer, I ran WarningCharacterizationTests and confirmed the existing WarningBaseline.txt matched HEAD. I regenerated it after the fix and reviewed every changed line. All eight changed or removed lines are "Row Estimate Mismatch" warnings. Every one has the same cause. The old code divided by a thread-summed ActualExecutions on a node that is not on the inner side of a Nested Loops join.

Fixture	Before	After
eager_index_spool_plan.sqlplan	Node 1: 39x overestimated (warning)	No warning (4.9x, under the 10x gate)
memory_grant_wait_plan.sqlplan	12,329x overestimated (Critical)	1,541x overestimated (Critical)
memory_grant_wait_plan.sqlplan	124x overestimated (Critical)	15x overestimated (Warning)
parallel-skew.sqlplan	392x overestimated (Critical)	98x overestimated (Warning)
serially-parallel.sqlplan	1,249x overestimated (Critical)	156x overestimated (Critical)
slow-multi-seek.sqlplan	10x overestimated (warning, right at the gate)	No warning
spill_plan.sqlplan	12,329x overestimated (Critical)	1,541x overestimated (Critical)
spill_plan.sqlplan	124x overestimated (Critical)	15x overestimated (Warning)

None of the 61 committed fixtures exercises the rule 16 or rule 26 fix. One way is an outer child that is itself on the inner side of an ancestor join. Another way is a row-goal scan that is not on the inner side of a Nested Loops join in a parallel zone. So the baseline diff has no lines from those two rules. The AnalyzerRuleGateTests above cover both directly, with hand-built trees.

Full suite: dotnet test tests/PlanViewer.Core.Tests/PlanViewer.Core.Tests.csproj -c Release passed. 1,007 tests succeeded, 1 skipped (an existing non-Windows-only test), 0 failed. dotnet build PlanViewer.sln -c Release --no-incremental succeeded with 0 warnings.

Checklist

• I have read the contributing guide
• My code builds with zero warnings (dotnet build -c Debug)
• All tests pass (dotnet test)
• I have not introduced any hardcoded credentials or server names

Fixes #594
Fixes #595

🤖 Generated with Claude Code

https://claude.ai/code/session_01G625JBNh45iTR1hpT4CxNR

[claude]

Reviewed. The change looks good: a single RowEstimateHelper now decides the expected row count, so the viewer, the analyzer and the Web app agree. It is linked into PlanViewer.Web.csproj, and tests and the warning baseline were updated. I found no crash, untrusted-input or convention issues.