[FEATURE] Web: general feedback

[jobbish-sql]

Which component(s) does this affect?

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

Problem Statement

I tried out the web version to give some feedback:

1. The darling-data-logo.png file in the top left is too small to read
2. I can upload a plan and see warnings: 25 but the 25 number is the total of warnings, info, and critical issues combined.
3. For multi-statement actual plans, it would be very cool if there was some kind of table of contents or summary at the top that ranked the statements by actual time/cpu time/whatever. That would make it easier to go to the statement that is the biggest problem. Right now you're showing cost at the top but a scrollbar appears with 10+ items on my 1080p monitor. We also all know how you feel about operator costs.
4. It would be helpful to give more horizontal space for the wait stats.

Everything below this is specific to an actual plan which I will send to you privately

5. STATEMENT 1: Plan gives a warning for "Query running serially: MAXDOP is set to 1." even though it's a simple variable assignment with a constant scan that takes 0 ms of actual time. The plan also has a cost of 0 units. I think it would be good to add some gatekeeping in terms of when you show the MAXDOP 1 warning.
6. STATEMENT 1: This query assigns a value to a local variable, but I'm getting the "Local Variables Local variables detected..." warning. Not sure if it's reasonable to hide that warning if the only local variable in use is used for assignment purposes. I will note that talking about OPTION (RECOMPILE) doesn't make sense here and there's no issue when the statement is taking 0 ms. Also worth thinking about just the volume of warnings that will be generated by a stored procedure which happens to be using local variables.
7. STATEMENT 5: "Filter operator discarding rows late in the plan. • 263 of 555 rows discarded (47%) • 19 logical reads below" - the only child operator is an index seek that takes 0 ms. The filter itself takes 1 ms. As noted in the warning, there was 19 logical reads done. Isn't this going to flag nearly every filter operator as a warning? Maybe set some kind of thresholds or something?
8. STATEMENT 6: "Excessive Grant: Requested 2,624 KB, Granted 2,624 KB, Used 16 KB" I'm personally not concerned about an excessive grant of 2 MB. Maybe hide based on EstimatedAvailableMemoryGrant or some other logic?
9. STATEMENT 8: it looks like the merge interval tricked the tool into a false positive warning about the "Join OR Clause"
10. STATEMENT 10: "Rewrite as an inline table-valued function, or dump results to a #temp table and apply the UDF only to the final result set." - other options include writing to a local variable or making eligible for UDF inlining (depending on the version of SQL Server)
11. STATEMENT 10: Some of the "Filter operator discarding rows late in the plan" warnings do not have stats for logical reads and time of their child operators
12. STATEMENT 10: "InfoIndex Seek (Node 160)Row Goal Row goal active: estimate reduced from 1 to 1 (1x reduction)"

Proposed Solution

:^)

Use Case

:^)

Alternatives Considered

no

[erikdarlingdata]

All 12 items addressed

Fixes landed in PerformanceStudio (PRs #177, #179, #180) and ported to PerformanceMonitor Dashboard + Lite (PR erikdarlingdata/PerformanceMonitor#795).

False positive fixes

#5 — MAXDOP 1 on trivial statements (Rule 3)
Added StatementSubTreeCost >= 0.01 gate. A variable assignment with a Constant Scan at cost ~0.000001 no longer warns about serial execution.

#6 — Local variable on assignments (Rule 20)
Same cost gate (>= 0.01). Simple SELECT @var = value statements are skipped — the warning only fires on statements where estimate quality actually matters.

#7 — Filter operator on trivial I/O (Rule 1)
Added impact thresholds. For actual plans: suppress when child subtree has < 128 logical reads AND < 10ms elapsed. For estimated plans: suppress when child subtree cost < 1.0. The 19-read / 0ms filter from Statement 5 is now correctly suppressed.

#8 — Memory grant noise (ShowPlanParser)
The XML MemoryGrantWarning element is now gated at 1 GB (1,048,576 KB), matching the analyzer's Rule 9 threshold. All example plans confirmed KB units. A 2 MB grant no longer fires a warning.

#9 — Merge Interval false positive (Rule 15)
IsOrExpansionChain() now checks if the Nested Loops at the top of the Concatenation→TopN Sort→Merge Interval→Nested Loops chain has a parent whose LogicalOp contains "Semi". If so, it's a NOT IN/IN subquery pattern, not an OR expansion. Statement 8's anti-semi join is correctly excluded.

#11 — Filter missing child stats (Rule 1)
The trivial filter suppression from #7 eliminates the warnings that would have shown empty stats. The QuantifyFilterImpact method's existing > 0 guards prevent displaying zero values for estimated plans.

#12 — Row Goal 1→1 (Rule 26)
Now requires reduction >= 2.0 before firing. "1 to 1 (1x reduction)" and tiny floating-point differences that display identically with N0 formatting are suppressed.

Message improvements

#10 — UDF rewrite suggestions
Expanded from "Rewrite as an inline table-valued function, or dump results to a #temp table" to include: assigning to a variable when only one row is needed, and checking SQL Server 2019+ automatic scalar UDF inlining eligibility.

Web UI improvements

#1 — Logo too small
Replaced the small color_logo_transparent.png with the full Darling Data barbell logo from erikdarling.com. Height bumped from 28px to 40px.

#2 — Warning count mixes severities
The single combined badge is replaced with up to three color-coded badges: red for Critical, orange for Warning, blue for Info. Each only appears if that severity has warnings.

#3 — Multi-statement ranking
Statement tabs are now sorted by elapsed time (actual plans) or estimated cost (estimated plans), descending. The slowest/most expensive statement is always the first tab — no scrolling needed to find the problem statement. Original statement numbers are preserved in the labels.

#4 — Wait stats horizontal space
Wait type column widened from 120px to 180px. When the waits card has data, it spans two grid columns for more room.

Estimated vs. actual plan handling

All threshold gates properly handle both plan types:

• Actual plans use runtime stats (reads, elapsed time)
• Estimated plans fall back to cost-based thresholds
• No runtime-only gates on estimated plans

[jobbish-sql]

Using the same plan as before:

13. There are orange numbers at the top next to each statement - I assume that this is supposed to be the number of warnings, but it often doesn't match.
14. It would also be good to have more horizontal space for the parameters because there's often a scroll bar and the other boxes have a lot of empty space.
15. I believe that TRIVIAL plans cannot be parallel, so it would be good to hide the MAXDOP 1 warning for them.
16. With respect to the MAXDOP 1 warning, what exactly is it that you want the end user to do in response to it? Is it possible to only make it a warning if the end user is doing something to explicitly disallow parallelism and to otherwise make it an info message or to not show it at all? It still feels like there's a lot of noise here. If my serial actual query takes 0 ms then why does it matter if it ran with MAXDOP 1?

[erikdarlingdata]

Round 2 items addressed (13-16)

#13 — Warning count mismatch on statement tabs
The tab badges were only counting statement-level warnings, not node-level. Now uses the same GetAllWarnings() total as the main warnings strip.

#14 — Parameters card needs more horizontal space
Parameters card now spans 2 grid columns when populated, same treatment as wait stats.

#15 — TRIVIAL plans shouldn't warn about MAXDOP 1
TRIVIAL optimization level now suppresses the serial plan warning entirely — these plans can't go parallel regardless.

#16 — MAXDOP 1 still too noisy
Three changes:

• Suppressed when actual elapsed is 0ms (query finished instantly, who cares)
• Demoted to Info severity when the reason is passive (EstimatedDOPIsOne, CouldNotGenerateValidParallelPlan) — the optimizer chose serial, not the user
• Only stays Warning when the user explicitly forced serial (MAXDOP set to 1 or OPTION(MAXDOP 1) hint)

All changes ported to PerformanceMonitor Dashboard + Lite (PR #797).

[erikdarlingdata]

Rule 3 (Serial Plan) — full NonParallelPlanReason coverage

Expanded to cover all 25 known reasons with human-readable messages and proper severity categorization.

Warning (actionable — user can rewrite or change config):

• MaxDOPSetToOne, QueryHintNoParallelSet, ParallelismDisabledByTraceFlag
• CouldNotGenerateValidParallelPlan
• TSQLUserDefinedFunctionsNotParallelizable, CLRUserDefinedFunctionRequiresDataAccess
• NonParallelizableIntrinsicFunction
• TableVariableTransactionsDoNotSupportParallelNestedTransaction
• UpdatingWritebackVariable, DMLQueryReturnsOutputToClient
• NoParallelCursorFetchByBookmark, NoParallelDynamicCursor, NoParallelFastForwardCursor
• NoParallelWithRemoteQuery, NoRemoteParallelismForMatrix

Info (passive or environmental):

• EstimatedDOPIsOne
• NoParallelPlansInDesktopOrExpressEdition, NoParallelCreateIndexInNonEnterpriseEdition
• NoParallelPlansDuringUpgrade, NoParallelForPDWCompilation, NoParallelForCloudDBReplication
• NoParallelForMemoryOptimizedTables, NoParallelForDmlOnMemoryOptimizedTable, NoParallelForNativelyCompiledModule
• MixedSerialAndParallelOnlineIndexBuildNotSupported, NoRangesResumableCreate

Still suppressed entirely:

• TRIVIAL optimization level
• StatementSubTreeCost < 0.01
• Actual elapsed time = 0ms

Landed in PerformanceStudio #193 and PerformanceMonitor #800.

[jobbish-sql]

It looks like if MAXDOP 1 is set at the database level (and presumably the server level and RG level too, but I didn't test this) then you always get warnings for MAXDOP 1. Can you think of any way to change that? IMO it would be better to show that case as info.

[erikdarlingdata]

@jobbish-sql I'll move around whatever you think is best, but I need to know how to differentiate things.