Release v1.7.6 — C1 memory color + C4 compile time + C8 expensive-op + C9 columnstore#264
Merged
Conversation
…anel (#215 C1, C4) (#261) C1: memory grant utilization color was too harsh. Old thresholds said anything under 80% used was warn/bad, so a 61% grant showed orange. Joe's point: operators spill near their max grant, so moderate utilization is fine and even preferable; what we actually want to flag is significant over-granting (very low utilization, reserved memory wasted). New thresholds: >= 40% utilized: good (neutral / green) 20-39%: warn (orange) < 20%: bad (red) Applied in three places: - PlanViewerControl.EfficiencyColor (used for memory grant, DOP efficiency, and thread utilization — loosens all three consistently) - HtmlExporter memory card eff class - Index.razor memory card eff class C4: compile time is now shown as a plan-level property in the Runtime panel of all three surfaces regardless of whether Rule 19 fires, per Joe's point that compile time belongs in the category-B "plan-level" grouping. Previously only visible when compile CPU >= 1000ms via the warning. Small `Compile: Nms` row next to Elapsed/CPU/DOP. Version bump 1.7.4 -> 1.7.5. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…215) (#263) C9: Rule 34 (Bare Scan) previously only fired when the scan output was ≤3 columns, since rowstore nonclustered indexes get expensive with more columns. Joe's point: columnstore (CCI/NCCI) doesn't care about column count, so a wide bare scan with nothing to suggest is a missed recommendation. Rule 34 now also fires on wide outputs (>3 columns) with columnstore-focused advice. Narrow-output path keeps the NC-index advice as before. C8: new Rule 35 "Expensive Operator" — emits when an operator's self- time is ≥20% of statement elapsed AND no other warning has already fired on the node. Ensures large work doesn't disappear just because the tool has nothing specific to suggest (Joe's scan-with-nothing-to-say case). Benefit % = self-time share; severity Critical at ≥50%, Warning otherwise. Self-guarded against existing warnings so it never stacks on top of a spill/lookup/etc. Neither rule fires on Joe's private plan (every significant operator already has a warning) or on 20260415_1.sqlplan (parallel work split). That's the expected "no false positives" behavior. Version bump 1.7.5 -> 1.7.6. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Batched release covering four items from #215:
Test plan
🤖 Generated with Claude Code