[BUG] Row-estimate rule 5 warns about resource allocation on operators that never executed

[nmummau]

Component

Desktop App (Windows)

Performance Studio Version

1.127.0

Operating System

Windows 11

Describe the Bug

Not proven yet so we should build a sqlplan that proves this.

Rule 5 treats zero actual rows as evidence that an operator allocated resources for rows that never materialized. It checks HasActualStats, but does not exclude ActualExecutions == 0 before entering this branch.

A runtime-statistics record with zero executions therefore generates the same warning as an executed operator returning zero rows. An unexecuted operator'szero row count is not evidence of a cardinality-estimation failure or of that operator allocating resources at runtime.

Steps to Reproduce

Run:

var node = new PlanNode
{
    PhysicalOp = "Sort",
    HasActualStats = true,
    ActualExecutions = 0,
    ActualRows = 0,
    EstimateRows = 1000
};
var plan = new ParsedPlan
{
    Batches = [new PlanBatch
    {
        Statements = [new PlanStatement { RootNode = node }]
    }]
};

PlanAnalyzer.Analyze(plan);
foreach (var warning in node.Warnings)
    Console.WriteLine($"{warning.WarningType}: {warning.Message}");

Expected Behavior

Rule 5 does not infer a runtime estimate mismatch from an operator that never executed.

Actual Behavior

A Row Estimate Mismatch warning is emitted:

Estimated 1,000 rows but actual 0 rows returned. SQL Server allocated resources for rows that never materialized.

Relevant code

• Rule05_RowEstimateMismatch

Suggested fix and regression coverage

Exclude operators with actual statistics and zero executions before evaluating the mismatch. Test unexecuted Sort, Hash Match, and Spool operators, alongside an executed zero-row operator that should still receive the existing analysis.

[erikdarlingdata]

Fixed by #582, merged to dev. Ships in the next release.