Narrow audit_config's collection, bound the regression baseline, bucket PG CPU (#4192, #4195, #4193, #4217)

[erikdarlingdata]

Closes #4192. Closes #4195. Closes #4193. Closes #4217.

Why

Three MCP read tools were slow or oversized. A Mac-side vendor-style perf review measured each one directly:

• audit_config answers from 8 point-in-time facts (CTFP, MAXDOP, max memory, max worker threads, edition, hardware, physical memory, database size). It ran the full analysis engine to get them. That engine collects roughly 30 fact families, including the plan-regression read measured at 4.8 s mean / 6.5 s max on a production store. It also runs the anomaly detector's baseline reads and the scorer. Measured at 7-15 s per call on the web Config tab.
• get_query_store_regressions compared a recent window against a baseline defined as every query_store_stats row the store still retains before the window, with no lower bound. The read's cost tracked retention, not the window asked for. Measured at 5-9 s per call, about 70k shared blocks read per call, on a fleet store with about 113M rows.
• get_pg_cpu_utilization never adopted the Trend tools return every raw point: get_file_io_trend sends 12,451 points / 1.4 MB for one server at defaults, more than an LLM client's context #3897 TrendBuckets contract the rest of the trend family (including its SQL Server twin, get_cpu_utilization) already carries. It returned one row per raw 1-minute Performance Insights sample for the whole window regardless of size. That gave 618 KB for a day. With the V136 host-memory columns doubling the row width, a week reached 4.1 MB.
• (WPF desktop viewer's Query Store Regressions grid still has an unbounded baseline (#4195 twin) #4217, found while finishing get_query_store_regressions' baseline is every retained row before the window (no lower bound): 5–9 s per call on a large store, the slowest read on the web Queries tab #4195) The WPF desktop viewer's Query Store Regressions grid (ViewerDataService.QueryStoreRegressions.cs) had the same unbounded-baseline shape as the MCP tool before get_query_store_regressions' baseline is every retained row before the window (no lower bound): 5–9 s per call on a large store, the slowest read on the web Queries tab #4195. It was a third, separate copy of the defect, in a different subsystem.

What changes

#4192: audit_config

Added a narrow CollectConfigAuditFactsAsync next to each collector's existing family methods: PgFactCollector for SQL Server targets, PgTargetFactCollector for PostgreSQL targets, and Lite's DuckDbFactCollector for parity. Each calls only the specific family methods audit_config actually reads. DarlingAnalysisService and Lite's AnalysisService each got a CollectConfigAuditFactsAsync(serverId, serverName, asOfUtc) wrapper: no coverage witness, no anomaly detector, no scorer. Output is unchanged: same fact keys, same recommendation logic.

#4195: get_query_store_regressions

Bounded the baseline to a fixed 7 days ending at the recent window's start (DarlingQueryStoreRegressionReader.BaselineLookbackDays). Passed as a 6th SQL parameter ($6), a plain timestamp, so TimescaleDB keeps plan-time chunk exclusion. The payload reports baseline_start and baseline_end explicitly. Lite's own copy of this tool had the same unbounded shape and is bounded the same way (LocalDataService.BaselineLookbackDays = 7).

#4193: get_pg_cpu_utilization

Added TrendBuckets.PgCpuMaxPoints (500, the widest cap in the family). Each point covers the CPU/ACU pair with peaks, the capacity trio, and six host-memory columns, about 500 bytes per point. DarlingPgCpuUtilizationReader.HistoryBucketedSql and GetBucketedHistoryAsync date_bin-bucket on sample_time, windowed on collection_time. CPU and ACU are averaged per bucket with each bucket's peak kept beside it.

memory_free_bytes and memory_active_bytes take each bucket's worst sample (min free, max active) rather than an average, so a pressure spike is not smoothed away. Routes through TrendBuckets.Resolve like the rest of the converted trend family. Lite has no PostgreSQL-target tools, so there is no Lite counterpart.

#4217: the WPF viewer's third unbounded copy

ViewerDataService.QueryStoreRegressions.cs's GetQueryStoreRegressionsAsync filtered its deduped_baseline CTE only on collection_time < $2 (the window start), with no lower bound. Its own doc comment said so directly. The viewer does not reference DarlingQueryStoreRegressionReader (a different project) or Lite's LocalDataService (a separate app). It keeps its own BaselineLookbackDays = 7 constant, matching the value the other two already keep independently. Added a $5 baseline-start parameter, computed in C# (startUtc.AddDays(-7)) rather than as a SQL interval. DarlingQueryStoreRegressionReader takes it the same way, for the same TimescaleDB chunk-exclusion reason.

Pinned with a source-text assertion for the new collection_time >= $5 bound (fails against the old shape, which had no $5 at all) and a live-Postgres case. Query 400's only baseline snapshot is 8 days before the window start. Before this fix, it joined and showed a 400% CPU regression. After, the INNER JOIN drops it for lacking a baseline inside the 7-day bound.

What the M1b lane did

The M1 lane hit its context budget partway through verification and left five known-red items plus the live-rig measurements outstanding. M1b fixed all five:

• A stale <see cref="Rounded"/> doc comment.
• Two McpToolsListBudgetTests/TotalCeilingBytes fixes.
• A stale PgTargetMcpSurfaceTests string literal.
• The ResolveEngineAsync call-site-count pins from 3 to 4 for the new CollectConfigAuditFactsAsync entry point.

M1b also bounded Lite's own regression baseline and got both full suites to 0 failed. No Postgres rig was available, so 691 live tests never ran on this branch.

What this lane (M1c) did

1. Fixed WPF desktop viewer's Query Store Regressions grid still has an unbounded baseline (#4195 twin) #4217 (see above): the viewer's third unbounded baseline copy, with a source pin and a live case.

2. Stood up the Postgres rig (port 55964) and measured before/after on this branch's own code. The full and narrow audit_config paths both still exist as separate, independently callable entry points on this build. So does the regression reader's baseline-bound parameter. That gives a same-build, same-fixture, same-connection comparison, not a dual-checkout one. Absolute numbers are from a small local fixture on a loopback rig, not the field's production-scale store. They show the shape of the fix (call-count and row-scan reduction), not the field's absolute 7-15 s / 5-9 s numbers. Those came from a pathological read at millions-of-rows scale this fixture does not reproduce.

   • audit_config: DarlingAnalysisService.CollectAndScoreFactsAsync (the full pass, still reachable directly) vs CollectConfigAuditFactsAsync (the narrow pass), 5 calls each, same minimal PG-target config/database-stats fixture. Full pass: 12.2 ms/call. Narrow pass: 6.2 ms/call. About 2x on a nearly-empty local store. The difference is purely call-count (about 30 family reads vs about 5), not the field's dominant pathological-read cost.
   • get_query_store_regressions: seeded 3 queries over a 30-day baseline (1 row/10 min, about 13k rows) plus a 2-hour recent window with one regression. DarlingQueryStoreRegressionReader.GetQueryStoreRegressionsAsync, 5 calls each. Unbounded-simulated (30-day baseline): 43.6 ms/call. Real 7-day bound: 10.6 ms/call. About 4.1x, tracking the about 4.3x row-count reduction. EXPLAIN (ANALYZE, BUFFERS) on the same two bounds: unbounded 588 shared buffer hits / 39.1 ms execution. 7-day: 141 shared buffer hits / 9.8 ms execution. About 4.2x fewer buffers, 4x faster.
   • get_pg_cpu_utilization: seeded 4 hours of 1-minute rows (240) with the V136 memory columns populated. At the tool's true default arguments (hours_back=4, no bucket_minutes): 59,646 bytes (58.2 KB), 119 points. The field number for the pre-get_pg_cpu_utilization never adopted the #3897 trend-bucket contract: 1-minute rows at any window, 618 KB for a day and 4.1 MB for a week #4193 shape at this same window was 103 KB (roughly 240 raw rows at about 430 bytes per row). That is a measured 43% reduction. The new shape is capped regardless of window width: a full week measured 84.5 KB where the old shape measured 4.1 MB. This does not reach the brief's "under 32 KB" target. The auto-bucketer targets TrendBuckets.McpPointBudget (200 points, shared by the whole trend family). A 240-minute default window lands on a 2-minute bucket width (119-120 points) rather than something coarser. Reaching 32 KB needs roughly 64 points. That target was estimated before this exact bucket-width choice was measured. Changing the auto-bucket-width formula is a product decision by the lane that built get_pg_cpu_utilization never adopted the #3897 trend-bucket contract: 1-minute rows at any window, 618 KB for a day and 4.1 MB for a week #4193. This lane is reporting the real, verified number.
   • Added get_pg_cpu_utilization to TrendPayloadBudgetLiveTests' roster (seeded pg_cpu_utilization, default-budget sweep + largest-answer cap-width check, alongside its SQL Server twin). Its own row is the widest in the family by design. It got its own PgCpuDefaultCeilingBytes (100 KB) in that test file. Raising the shared DefaultCeilingBytes (80 KB) weakens what that ceiling guards for the other ten, lighter trend tools. Measured 84,556 bytes / 169 points at a week on that fixture.

3. Ran this branch's live test classes for the first time. No rig was up on this branch before this lane. Found and fixed one real regression: DarlingQueryStoreRegressionsLiveTests (in DarlingQueryStoreRegressionsTests.cs) still asserted the old "Shorten hours_back" advice text in the no-baseline branch. get_query_store_regressions' baseline is every retained row before the window (no lower bound): 5–9 s per call on a large store, the slowest read on the web Queries tab #4195 correctly removed that line when it bounded the baseline. Shortening hours_back no longer changes how far back a fixed baseline reaches, so the advice no longer applies. The message rewrite never updated this test's pin. Fixed the assertion to match the current, correct message text.

4. Ran the full Darling.Tests.exe suite once, with the rig up. Dropped and recreated darlingtest first, then ran git merge origin/dev (already up to date). Result: 13,766 total, 0 errors, 3 failed, 47 skipped, 1 not run, 645.9 s. The named flake (ServerListAndSummaryPlanShapeTests.TheShippedReads_...) did not fail. Three failures are flagged for the coordinator:

   • TrendPayloadBudgetLiveTests.EveryDefaultAnswer_...: passed standalone (verified twice, before and after the roster addition). Failed only inside the full run with "Exception while reading from stream" on get_file_io_trend. Looks like a connection/resource hiccup under full-suite parallel load against a small local rig (100 max_connections, default shared_buffers), not a code defect. Not confirmed.
   • PgTargetAuditConfigTests.APostgresTarget_ProjectsItsConfigPgFacts_WithUnitsAndNoSuggestedValue: expected status "review", got "ok".
   • PgTargetAuditConfigTests.AnAuroraTarget_RendersTheCheckpointingKnobsNotApplicable_AndExcludesThemFromTheCheckedCount: expected "not_applicable", got "ok". Both PgTargetAuditConfigTests cases are scoring-outcome mismatches. Neither ran before (no rig on this branch until now, so both were always in the 691 skipped). CollectConfigAuditFactsAsync calls the same three family methods (CollectConfigFactsAsync/CollectMemoryFactsAsync/CollectVacuumFactsAsync) the full pass already called for a PG target. The cause is not confirmed. Do not assume pre-existing without checking.
   • Lite.Tests.exe was not run this lane. Context budget ran out after the Darling.Tests full run and rig teardown.

5. Stopped the rig and deleted C:\GitHub\worktrees\rig-m1c when finished.

Test plan

• dotnet build Darling/Darling.Tests/Darling.Tests.csproj: 0 Warning(s), 0 Error(s) (rebuilt after every change in this lane).
• dotnet build Lite.Tests/Lite.Tests.csproj: 0 Warning(s), 0 Error(s) (M1b's last build. M1c's only Lite-adjacent change was WPF desktop viewer's Query Store Regressions grid still has an unbounded baseline (#4195 twin) #4217's WPF viewer, which does not affect Lite).
• Live-PostgreSQL rig stood up (port 55964) and measured. See "What this lane did" above for all numbers.
• get_pg_cpu_utilization added to TrendPayloadBudgetLiveTests' roster and passing standalone.
• Live classes in every file this branch's diff touches, run against the rig. Found and fixed one stale assertion (DarlingQueryStoreRegressionsLiveTests). ViewerQueriesLivePostgresTests (with the new WPF desktop viewer's Query Store Regressions grid still has an unbounded baseline (#4195 twin) #4217 case) and DarlingAnalysisServiceEngineRoutingTests pass.
• Full Darling.Tests.exe (no filter) with the rig up: 13,766 total, 0 errors, 3 failed, 47 skipped, 1 not run, 645.9 s. Three failures flagged above.
• Full Lite.Tests.exe: not run this lane. Context budget ran out.
• The known flake named in the brief (ServerListAndSummaryPlanShapeTests.TheShippedReads_...) did not fail.

CHANGELOG entry

SECTION: Fixed
ENTRY:

• audit_config no longer runs the full analysis pass ([Narrow audit_config's collection, bound the regression baseline, bucket PG CPU (#4192, #4195, #4193, #4217) #4206]). It read a full ~30-family collection, detector and scorer pass just to answer 8 point-in-time configuration facts, measured at 7-15 seconds per call. It now runs only the specific family reads those 8 facts come from. The facts and recommendations returned are unchanged.
• get_query_store_regressions' comparison baseline is now a fixed 7 days ([Narrow audit_config's collection, bound the regression baseline, bucket PG CPU (#4192, #4195, #4193, #4217) #4206]). The baseline used to be every Query Store capture the store retained before the requested window. Both cost and the comparison period grew with retention. It is now a fixed 7-day lookback ending at the window's start, reported as baseline_start and baseline_end in the response. A regression against something that changed more than 7 days before the window is no longer caught. A store retaining less than 7 days is unaffected. Performance Monitor Lite's own copy of this same tool had the same unbounded baseline and is fixed the same way.
• get_pg_cpu_utilization now returns bucketed points instead of one row per minute ([Narrow audit_config's collection, bound the regression baseline, bucket PG CPU (#4192, #4195, #4193, #4217) #4206]). A wide window (a week, or longer with the V136 host-memory columns) returned several megabytes per call. It now buckets to a point budget the same way the rest of the trend family does. It averages CPU/ACU per bucket while keeping each bucket's peak. The worst (not average) memory-pressure sample per bucket is kept, so a brief spike is not smoothed away.
• The desktop viewer's Query Store Regressions grid had the same unbounded-baseline shape as get_query_store_regressions and is now bounded the same way ([Narrow audit_config's collection, bound the regression baseline, bucket PG CPU (#4192, #4195, #4193, #4217) #4206]). It was a third, separate copy of the defect, in the WPF app rather than the MCP surface, with its own 7-day fixed lookback.
  REF:
  [Narrow audit_config's collection, bound the regression baseline, bucket PG CPU (#4192, #4195, #4193, #4217) #4206]: Narrow audit_config's collection, bound the regression baseline, bucket PG CPU (#4192, #4195, #4193, #4217) #4206

Generated with Claude Code

https://claude.ai/code/session_01FVjn4PBJN71NQXdFo6ZxNQ