Claude posting for Erik Darling
Component
All: the shared parser in PlanViewer.Core (Services/ShowPlanParser.cs)
Performance Studio Version
main @ 7a16042 (after v1.27.0)
Operating System
Any
Describe the Bug
ShowPlanParser drops two statement shapes that carry their own plan or hashes. PerformanceMonitor's copy of this parser had the same two gaps, fixed in erikdarlingdata/PerformanceMonitor#4470 (issue erikdarlingdata/PerformanceMonitor#4468).
- An IF condition's own query plan (
StmtCond with StatementType="COND WITH QUERY"). ParseStatementAndChildren (~line 160) passes each child of <Condition> back into itself. For this shape the child is a bare <QueryPlan>, not a statement, so it falls to the else branch and ParseStatement reads the QueryPlan element as if it were a statement. StatementText and StatementType come back empty (those attributes live on the StmtCond), no nested QueryPlan is found (~line 272), and the method returns the synthetic STATEMENT root (~line 319). The condition's operator tree, and every missing-index suggestion and warning the analyzer would raise on it, are lost.
StmtSimple with StatementType="MULTIPLE PLAN". It carries QueryHash and QueryPlanHash but no QueryPlan child. ParseStatement returns at the no-QueryPlan branch (~line 319) before it reads the hashes (~lines 501–502), so both come back null.
Found by reading this code against the PerformanceMonitor fix. Not yet reproduced in Performance Studio itself.
Steps to Reproduce
- Capture an actual or estimated plan for a batch with an
IF EXISTS (SELECT ... FROM some_table WHERE ...) condition.
- Open or analyze it and look at the statement list.
Expected Behavior
- The IF condition appears as its own statement, with
StatementType COND WITH QUERY, its operator tree, its hashes, and any warnings.
- A
MULTIPLE PLAN statement keeps its QueryHash and QueryPlanHash.
Actual Behavior
From the code:
- The condition becomes an empty
STATEMENT placeholder with no operators.
- A
MULTIPLE PLAN statement's hashes are null.
Plan File
The shape, abbreviated:
<StmtCond StatementType="COND WITH QUERY" StatementText="IF EXISTS (SELECT ...)" ...>
<Condition>
<QueryPlan ...>
<RelOp ...> ... </RelOp>
</QueryPlan>
</Condition>
<Then> ... </Then>
</StmtCond>
Claude posting for Erik Darling
Component
All: the shared parser in
PlanViewer.Core(Services/ShowPlanParser.cs)Performance Studio Version
main@7a16042(after v1.27.0)Operating System
Any
Describe the Bug
ShowPlanParserdrops two statement shapes that carry their own plan or hashes. PerformanceMonitor's copy of this parser had the same two gaps, fixed in erikdarlingdata/PerformanceMonitor#4470 (issue erikdarlingdata/PerformanceMonitor#4468).StmtCondwithStatementType="COND WITH QUERY").ParseStatementAndChildren(~line 160) passes each child of<Condition>back into itself. For this shape the child is a bare<QueryPlan>, not a statement, so it falls to theelsebranch andParseStatementreads theQueryPlanelement as if it were a statement.StatementTextandStatementTypecome back empty (those attributes live on theStmtCond), no nestedQueryPlanis found (~line 272), and the method returns the syntheticSTATEMENTroot (~line 319). The condition's operator tree, and every missing-index suggestion and warning the analyzer would raise on it, are lost.StmtSimplewithStatementType="MULTIPLE PLAN". It carriesQueryHashandQueryPlanHashbut noQueryPlanchild.ParseStatementreturns at the no-QueryPlanbranch (~line 319) before it reads the hashes (~lines 501–502), so both come back null.Found by reading this code against the PerformanceMonitor fix. Not yet reproduced in Performance Studio itself.
Steps to Reproduce
IF EXISTS (SELECT ... FROM some_table WHERE ...)condition.Expected Behavior
StatementTypeCOND WITH QUERY, its operator tree, its hashes, and any warnings.MULTIPLE PLANstatement keeps itsQueryHashandQueryPlanHash.Actual Behavior
From the code:
STATEMENTplaceholder with no operators.MULTIPLE PLANstatement's hashes are null.Plan File
The shape, abbreviated: