[erikdarlingdata]

The CLI's "Expensive operators" list and the GUI's advice cards each did their own row-mode subtraction. It took only a batch child's own time, so a row-mode parent was charged the rest of the batch zone, for elapsed and CPU both. On param-sniffing-posttypeid2.sqlplan the Stream Aggregate (node 4) showed 14,771 ms CPU and 14,720 ms elapsed. PlanAnalyzer already gave it 3,059 ms of elapsed. The listed CPU shares added up to 159%.

Changes

• PlanAnalyzer.GetOperatorOwnCpuMs (new): own CPU summed across threads, with per-thread subtraction and batch zones summed.
• OperatorResult gets OwnCpuMs and OwnElapsedMs (own_cpu_ms and own_elapsed_ms in JSON) from ResultMapper. The text formatter and the advice cards read those instead of subtracting again.
• GetEffectiveChildCpuMs sums a batch child's zone, as the elapsed path does. This also fixes the serial path of GetOperatorMaxThreadOwnCpuMs.
• GetOperatorMaxThreadOwnCpuMs returns a batch operator's busiest thread without subtracting its children, as GetOperatorOwnElapsedMs does.
• NodeTimeAttribution.GetOwnCpuMs sums batch zones too.
• Two comments updated to match: the advice cards one (it no longer copies TextFormatter's subtraction) and NodeTimeAttribution's remark.
• From the round-1 review: the analyzer's own-time functions now fall back to the estimated execution mode when a node has no actual mode, as the child paths already did.
• From the round-2 review: GetOperatorMaxThreadOwnCpuMs keeps a batch node's total CPU when the node has no per-thread rows. Parsed plans always have them, so this only matters for nodes built in code.

Testing

• param-sniffing-posttypeid2.sqlplan, node 4: 3,112 ms CPU and 3,059 ms elapsed. The shares add up to 98%.
• Across the 60 test plans, the Expensive operators text changes on 10. Two plans listed CPU shares over 105% before, and none do now.
• Four new tests in OperatorSelfTimeTests.
• Core tests: 1,503 total, 0 failed, 40 skipped on Linux (31 on Windows). Before: 1,499 and 40.
• dotnet build of PlanViewer.sln: 0 warnings, 0 errors.

The same two CPU problems are fixed in the sqlserver-query-plans plugin (claude-plugins, version 1.5.6).

🤖 Generated with Claude Code

https://claude.ai/code/session_01UoaQ2xKMpZEXvm4HncT8ND

[claude]

Low: the batch check here (and in GetOperatorMaxThreadOwnCpuMs) reads node.ActualExecutionMode only. GetEffectiveChildCpuMs, AddEffectiveChildByThread and SumBatchSubtreeCpuMs use ActualExecutionMode ?? ExecutionMode. A node with no actual mode attribute but an estimated mode of Batch is subtracted as a child but treated as row mode when it is the parent. That mismatch would double-subtract. Use the same ?? ExecutionMode expression in both places, or put it in a small helper.

Tests are fine for the changed behavior. They cover the serial, parallel and batch cases and the CLI text.

[claude]

Regression risk: when a batch-mode node has no PerThreadStats (serial plan, or per-thread info absent), WorkThreads(node) is empty and DefaultIfEmpty(0).Max() returns 0. Previously the code fell through to the serial path and returned ActualCPUMs. GetOperatorOwnCpuMs right below handles this by returning node.ActualCPUMs. Fall back to node.ActualCPUMs when there are no threads, e.g. var threads = WorkThreads(node); if (threads.Count == 0) return node.ActualCPUMs;. The new tests only cover a parallel plan, so none of them catches this.

[claude]

Reviewed the diff. I found no blocking issues.

• Correctness: The CLI text report, the advice cards and the JSON output now read one set of own-time figures from PlanAnalyzer. That removes the two private row-mode subtraction copies. The new batch-zone CPU subtraction (SumBatchSubtreeCpuMs) stops at Parallelism boundaries, and the ActualExecutionMode ?? ExecutionMode fallback is applied consistently. I saw no null or empty-plan hazards, because the mapper only fills the new fields inside the actual-stats branch.
• Conventions: No new files, so PlanViewer.Web.csproj linking and the SSMS version files are unaffected. No SQL is generated, and I saw no new NoWarn.
• Tests: Coverage is good: serial-over-batch, parallel sum versus max-thread, batch max-thread, and the CLI text output.
• Minor, non-blocking:
  • own_elapsed_ms and own_cpu_ms are new JSON fields. Anything consuming the JSON should treat them as nullable, because they are null for estimated plans.
  • NodeTimeAttribution.SumBatchSubtreeCpuMs duplicates the analyzer's version. The remarks call the two paths intentionally separate, so this is acceptable.