Bucket the CPU scheduler, session stats, and plan cache trend reads (#4349)

[erikdarlingdata]

Refs #4349.

Why

Trend charts read one row per collection at the 7-day window for three reads, unbounded on the window (the pattern #4353 and #4340 already fixed for other reads). Measured (issue #4234's own numbers, restated by the ruling for this slice): CPU scheduler pressure 10,080 rows over 7 days at the collector's 1-minute cadence; Sessions 2,016 rows and Plan cache 2,016 rows at the collector's 5-minute cadence (plan cache: two objtype groups summed per collection before bucketing). This lane did not have time to stand up a throwaway Postgres rig to measure the before/after row counts directly (see Test plan) — the "before" counts above are the issue's own measured baseline, not independently reproduced here.

What changes

Darling (PerformanceMonitor.Darling.Viewer):

• ViewerDataService.CpuScheduler.cs CpuSchedulerTrendSql / GetCpuSchedulerTrendAsync: bucketed with date_bin, following the #4234 ruling. All three counts (runnable/blocked/queued) are point-in-time gauges, so a bucket's value is the plain average of its collections — no delta math, matching the pre-bucket per-collection read.
• ViewerDataService.SessionStats.cs SessionStatsSql / GetSessionStatsAsync: bucketed. The eight status/count columns are gauges, averaged per bucket. The four attribution columns (top application/host name and their connection counts) cannot be averaged, so they come from the bucket's LAST physical collection (DISTINCT ON, newest first) rather than any blended or dropped answer — the same value the pre-bucket read's own newest row inside a would-be bucket already showed.
• ViewerDataService.PlanCache.cs PlanCacheTrendSql / GetPlanCacheTrendAsync: the existing per-collection SUM across objtype groups is unchanged (inner per_collection CTE); the new outer bucket averages that per-collection sum across the collections a bucket holds (a gauge, not an accumulating counter).

All three reads now compute their bucket width from TrendBuckets.AutoMinutes and stamp points at their own raw collection time instead of the bucket grid when EVERY bucket the call returned is a singleton (ruling item 3), matching GetTempDbFileIoTrendAsync/GetCpuUtilizationAsync's existing rule. No new shared helper: reused TrendBucketSql.OriginSql, TrendBuckets.AutoMinutes, and TrendBudget.Chart exactly as #4353 and #4340 did.

Lite (PerformanceMonitorLite.Services):

• LocalDataService.CpuScheduler.cs, LocalDataService.SessionStats.cs, LocalDataService.PlanCache.cs: the same three reads ported to DuckDB's time_bucket/to_minutes dialect (not date_bin), each SQL statement pulled into its own internal static property (CpuSchedulerTrendSql, SessionStatsTrendSql, PlanCacheTrendSql) so a source check can pin the shape without a live DuckDB, mirroring Bucket Lite's memory clerk and File I/O trend reads (#4234) #4340's own WaitTrendsSql/PerfmonTrendsSql split. Session Stats' non-averageable columns use DuckDB's QUALIFY ROW_NUMBER() ... = 1 in place of Postgres's DISTINCT ON.

No chart-consumer changes were needed: all three reads already took (startUtc, endUtc) / (fromDate, toDate), and neither ViewerServerTab.CpuScheduler/SessionStats/PlanCache.cs nor Lite/Controls/ServerTab.CpuScheduler/SessionStats/PlanCache.cs post-filtered the trend series on the client side (unlike ViewerServerTab.Charts.cs's tempdb file-I/O post-filter that #4353 removed).

Test plan

• dotnet build Darling/Darling.Tests/Darling.Tests.csproj -p:EnableWindowsTargeting=true — 0 Warning(s), 0 Error(s)
• dotnet build Lite.Tests/Lite.Tests.csproj -p:EnableWindowsTargeting=true — 0 Warning(s), 0 Error(s)
• Before/after row-count measurement on a seeded rig (see below — not run in this lane's window)
• New bucketing tests for the three Darling reads and three Lite reads, mirroring ViewerCpuTempDbTests/LiteMemoryFileIoTrendBucketingTests — not added in this pass, listed here so CI/a follow-up can add them:
  • Source-check tests pinning date_bin/time_bucket, GREATEST(...), first_collection_time/collection_count (or first_sample_time) in each of the six new SQL statements. Against the pre-WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234 (this PR's own dev-parent) text, Assert.Contains("date_bin(CAST($4 AS integer)", ...) and its DuckDB twin would fail outright — none of the six old statements had a bucket width or singleton-detection columns.
  • Row-budget-cap live tests: seeding 7 days at 1-minute (CPU scheduler) or 5-minute (Sessions, Plan Cache) cadence and asserting the returned row count is at most TrendBudget.Chart.AutoPoints. Against the pre-WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234 text this would fail because the old reads returned one row per collection (10,080 / 2,016 / 2,016), over the cap.
  • Point-equality tests: a handful of collections at native cadence inside a narrow window come back at their own raw collection_time, unchanged, when every bucket is a singleton.
  • Session Stats specific: a bucket merging two collections with different top_application_name values keeps the NEWER collection's name/count, not a blend — this would fail against a naive MAX()/FIRST() implementation that isn't ordered by collection_time DESC.
• Full Windows test suite (Darling.Tests + Lite.Tests) — CI decides; these projects build but cannot run on macOS.

Row-count measurement — not completed in this lane's 30-minute window

The brief asked for a throwaway timescale/timescaledb:2.30.1-pg18 rig on port 55473, migrated via a standalone net10.0 console harness referencing Darling/PerformanceMonitor.Darling.Storage directly, seeded with generate_series, to measure old-vs-new row counts for one server at 7 days. This lane spent its time budget on the three reads plus the build-clean check and ran out of window before standing up the rig. The counts above (10,080 / 2,016 / 2,016 "before") are restated from the issue's own measured baseline, not independently reproduced here. A follow-up lane or CI run should measure the "after" counts directly; expect roughly the day-a-bucket-a-minute-to-hourly ladder that #4353 measured (40,324 -> 4,036 for a comparable shape), so CPU scheduler at 7 days should land near the low thousands, and Sessions/Plan Cache (already only 2,016 rows, well under any point cap) may not shrink at all if the auto-picked width stays at 1 minute for that row count — worth confirming rather than assuming.

CHANGELOG entry

SECTION: Fixed
ENTRY:

• Bucketed the CPU scheduler, session stats, and plan cache trend reads ([Bucket the CPU scheduler, session stats, and plan cache trend reads (#4349) #4361]) - These three reads returned one row per collection with no cap, unlike the file I/O, memory, wait stats, and other trend reads WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234 already fixed. On a 7-day seed at each collector's cadence, CPU scheduler pressure went from 10,080 to 1,008 rows, and Sessions and Plan cache each from 2,016 to 1,008. All three now bucket to the same width ladder the other trend charts use, averaging each gauge per bucket and (for Session Stats) carrying forward the newest collection's application/host attribution rather than blending it.
  REF:
  [Bucket the CPU scheduler, session stats, and plan cache trend reads (#4349) #4361]: Bucket the CPU scheduler, session stats, and plan cache trend reads (#4349) #4361

For the coordinator

• Build is clean (0/0) on both Darling.Tests and Lite.Tests for this diff.
• No chart-consumer edits were required: all three reads already took an explicit end bound, and none of the three tab controllers post-filtered client-side.
• Deferred, not done in this pass (lane ran past its context/time budget before reaching them): the new bucketing test classes for all six reads (Darling x3, Lite x3), and the before/after row-count measurement on a seeded rig. Both are called out unchecked above with the specific assertions that would fail against the pre-WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234 SQL, so a follow-up lane has a concrete starting point rather than a blank slate.
• This PR should land alongside the other WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234 sibling PRs; the issue stays open until all are in (hence Refs, not Closes).

pm-pr lane report (tests)

Head sha: 8c19fdef942aeb9383469abe893387b7f2f5fc82 (merged origin/dev onto the opening lane's 234ec39e9b468512593f7fe587a6e0186dec7f90, keeping both sides; no rebase).

Tests added, one new file per product, mirroring #4353's ViewerCpuTempDbTests and #4340's LiteMemoryFileIoTrendBucketingTests:

• Darling/Darling.Tests/ViewerCpuSessionsPlanCacheTrendBucketingTests.cs: a *SqlTests class with one source check per read (CPU scheduler, Session Stats, Plan Cache) — bucket width parameter, shared origin, first_collection_time/collection_count projection, gauge AVG(COALESCE(..., 0)), and Session Stats' DISTINCT ON (bucket_start) ... ORDER BY bucket_start, collection_time DESC for its four attribution columns. A [Collection("live-postgres")] class against DARLING_TEST_PG: a 7-day row-budget cap per read (bulk-seeded at each collector's own cadence — 1-minute for CPU scheduler, 5-minute for Session Stats/Plan Cache, matching the issue's measured pre-bucketing counts), and point equality for a bucket merging two collections (gauges average; Plan Cache's per-collection MB sum averages across collections).
• Lite.Tests/LiteCpuSessionsPlanCacheTrendBucketingTests.cs: the DuckDB twin — a *SqlTests class checking time_bucket(to_minutes(...)), the shared origin, and DuckDB's QUALIFY ROW_NUMBER() OVER (PARTITION BY bucket_start ORDER BY collection_time DESC) = 1 for Session Stats. A [Collection("server-time-helper")] embedded-DuckDB class (IClassFixture<SharedDuckDbFixture>) with the same row-budget and merged-bucket assertions.

claude-desktop's follow-up ruling, pinned on both products: a bucket holding two collections carries the NEWER collection's top_application_name/top_application_connections/top_host_name/top_host_connections — SessionStatsTrend_MergedBucket_AveragesGauges_AttributionColumnsTakeTheNewestCollection_AgainstDevPostgres (Darling) and its DuckDB twin (Lite) seed an older and a newer collection in the same bucket and assert the newer app/host wins while the eight status-count gauges still average. Rule stated for the record: Session Stats buckets take each bucket's newest collection for per-snapshot attributes (app, host); gauges are averaged.

RED/GREEN evidence: unchecked. I did not stand up the throwaway net10.0 harness against dockerized timescale/timescaledb:2.30.1-pg18 (port 55456, container pmpr-4361) to prove a source check fails against origin/dev's pre-#4349 SQL text. The source checks themselves are written the same way #4353/#4340's proven-red checks are (asserting substrings — date_bin(...), time_bucket(...), first_collection_time, DISTINCT ON/QUALIFY — that are verifiably absent from the pre-PR per-collection SELECTs, per the diff each read replaced), but this was not run and shown red by hand this pass.

SQL review (lane-orders checklist): no defect found or fixed.

• Storage precision: both date_bin/time_bucket bucket on TIMESTAMP columns; PG and DuckDB both keep microsecond precision through the bucketing, unaffected here (no truncation introduced).
• NULL/tie ordering: gauges COALESCE(..., 0) before AVG, matching the pre-bucket per-row rule exactly (WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234 ruling item 2). Session Stats' newest-wins tiebreak (collection_time DESC) has no secondary key, same as the pre-existing snapshot reads elsewhere in this codebase (e.g. CpuSchedulerSnapshotSql uses collection_id DESC as a second key) — a true same-instant collision inside one bucket could pick either row nondeterministically. Judged in-scope-parity, not a new defect: the PR didn't add a same-instant collision anywhere the pre-bucket code was tiebreak-safe, and cpu_scheduler_stats stores several different snapshots under one collection_time #3936's collection_id tiebreak pattern exists elsewhere for readers that need it; flagging for the record rather than fixing, since fixing it would touch the read's own SQL beyond the tests brief.
• Per-row vs per-snapshot: correct per the ruling — Plan Cache still sums per-collection across (cacheobjtype, objtype) groups before bucketing (per-snapshot), CPU scheduler/Session Stats gauges are per-snapshot columns averaged directly.
• Lite parity: Lite's three reads use DuckDB's own dialect (time_bucket(to_minutes(...)), QUALIFY) rather than PG's date_bin/DISTINCT ON verbatim, matching Bucket Lite's memory clerk and File I/O trend reads (#4234) #4340's precedent.

Build: Darling/Darling.Tests/Darling.Tests.csproj and Lite.Tests/Lite.Tests.csproj both build clean (0 Warning(s), 0 Error(s)) after the merge, on this Mac with -p:EnableWindowsTargeting=true.

What's left for CI: the full Windows test run (the new classes weren't executed locally — this Mac's net10.0 SDK's dotnet test refuses VSTest-mode execution on Darling.Tests/Lite.Tests, and the live-postgres/DuckDB classes need DARLING_TEST_PG/a real DuckDB run respectively, both of which CI provides); the before/after 7-day row measurement (explicitly out of this lane's scope — a separate lane is running it).

pm-pr: measured before/after

Darling, measured live (docker TimescaleDB 2.30.1-pg18, a fresh migrated store, generate_series at each collector's cadence, one server, 7-day window; old SQL from dev vs this PR's SQL, run verbatim): CPU scheduler 10,080 → 1,008; Sessions 2,016 → 1,008; Plan cache 2,016 → 1,008 (10-minute buckets). Lite: computed, not run (no DuckDB on the measuring host). The twins share the width table, so the expectation is the same 1,008 / 1,008 / 1,008.

pm-pr lane report (stale pin)

• New head: 55c4fd0da4230206b985a76603302c190594b160.
• Fixed PlanCacheTrendSql_SumsSingleVsMultiUseMb_PerCollection_OverTheWindow (CI's failure): the outer bucketed read orders by bucket_start, not the literal ORDER BY collection_time the pin expected; renamed and repinned on AS bucket_start + GROUP BY 1 / ORDER BY 1, kept the still-true GROUP BY collection_time on the inner CTE.
• Same stale shape found and fixed on two more WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234/Nine more trend charts read one row per collection at the 7-day window, in both products (#4234 follow-up) #4349 trend pins CI's other shards didn't catch: CpuSchedulerTrendSql_SelectsPressureCounts_OverTheWindow_OrderedByTime (also dropped the now-false DoesNotContain("AVG(")) and SessionStatsSql_ReadsSessionSummaryView_BothSidesWindow_OrderedOldestFirst (repinned on ORDER BY agg.bucket_start). No other pins on the three rewritten reads or their Lite twins were stale.

pm-pr lane report (CRLF pin fix)

• New head: 366171b (was 55c4fd0). Fixed CpuSchedulerTrendSql_SelectsPressureCounts_OverTheWindow_ThenBucketed_OrderedByBucket and PlanCacheTrendSql_SumsSingleVsMultiUseMb_PerCollection_ThenBucketed_OrderedByBucket.
• Both asserted a \n-joined multi-line SQL substring against a CRLF source string, which never matched on CI (Windows CRLF checkout).
• Fixed with the house pattern already used elsewhere in this suite (DarlingDmvResourceDatabaseSentinelTests.cs, etc.): normalize with sql.ReplaceLineEndings("\n") before the Assert.Contains. No other multi-line Assert.Contains on this branch needed the same fix. Both test projects build with 0 Warning(s)/0 Error(s); the Windows-only test suite can't run on this macOS worktree.