A quiet hour halved the next hour's Query Store rate, and three trend readers recomputed an interval the store had stored all along: rollup points are rated over their own bucket width, the query-stats trends read sample_interval_seconds three-state on both SKUs, and Compose delta aggregates FILTER out the restart marker (partial #3653: A8, A11's LAG clause, the Cumulative archetype)

[erikdarlingdata]

Three lies on one theme: a rate or an aggregate over a differenced series must use the interval the store HAS

Partial #3653 — the measurement layer's A8 Rollup rate denominators, the LAG-recompute clause of A11 assorted, and the Compose MeasureCatalog Cumulative archetype item. Three items, one lane, because they share files and they share a mechanism: each computed a denominator (or admitted a row) from something the store had never claimed — row spacing, or an unread marker — when the store was carrying the honest number beside it.

A. A quiet hour halved the next hour's Query Store rate (QueryStoreTrendRouting.BuildRollupTrendSql)

The rollup-routed Query Store trend unions two point classes — corrected-hourly buckets below the materialization watermark, raw interval-placed points above it — and then rated every point over LAG(point_time): the gap to the previous EMITTED point. A corrected-hourly bucket with no rows (no executions that hour, or an unmaterialized hole) is simply absent from rollup_points, so the bucket after it saw a 7,200-second gap and published half its true executions/sec and duration-ms/sec. On a store whose overnight is quiet, every first busy hour of the morning read at 50%.

The shape. Each united point now carries its class (from_rollup), and the rated CTE divides on it: a rollup point over its bucket width — DurationTrendRouting.HourlyBucketSecondsSql, the same literal the query-stats hourly tier divides by, pinned equal to TimescaleSupport.HourlyBucket — and a raw point over the spacing LAG it always used. The corrected hourly carries no covered-seconds column (read from CreateQueryStoreStatsCorrectedHourlySql: execution_count_sum, the weighted sums, sample_count, nothing about time), and a CAGG cannot be altered in place (#3653 A6), so the bucket width is the honest denominator for a bucket that IS materialized, and a bucket that is a hole produces no point — a gap in the series, which is what a quiet hour is.

A consequence, stated: a rollup point is never unrated — the window's first bucket has a known denominator exactly as the query-stats hourly tier's first bucket does — so the first-point NULL of #3541 A12 is now a raw-class rule. The existing live pin (QueryStoreTrendRoutingLiveTests: first united point unrated) is moved deliberately: that point was a rollup bucket whose denominator was known all along, and it now reads 21 / 3,600.

The residual, named on the CTE rather than hidden: a raw point is a Query Store interval placed at its start, and query_store_stats stores no interval length (it is a cumulative-snapshot source outside the ten delta families; it carries interval_start_time_utc but not the width). So the raw class keeps the spacing denominator, and a quiet Query Store INTERVAL before a raw point still halves it — the new live test asserts that residual beside the fix (25 / 7,200 on the raw-only route, 25 / 3,600 on the rollup route, same rows). Removing it needs the interval length stored beside the row: a collector change and a rung, not a read change. The seam LAG (first raw point differenced against the last rollup bucket) is kept: on the default INTERVAL_LENGTH_MINUTES = 60 it is exactly one bucket, and partitioning the LAG by class would make the most-looked-at point on a now-anchored chart unrated for nothing.

B. Three trend readers LAG-recomputed an interval query_stats stored from the start

query_stats (and procedure_stats) have carried sample_interval_seconds since their first rung, stamped per row by the shared delta calculator from the SAME two collection instants a LAG(collection_time) re-derives. On a steady series the two agree to the second. They differ exactly where they must: a row the calculator could not difference (first sighting, counter reset, gap past policy — in practice a restart) stores 0 beside a 0 delta, and the LAG divided that fabricated 0 by the real elapsed seconds into a confident 0.00 ms/sec at the instant nothing was knowable. V128 (#3540) moved the procedure trends to the stored interval and reported the query-stats copies as the A11 residual; this PR rewrites them.

The shape. DurationTrendRouting.BuildRawTrendSql(rawTable, withDatabaseFilter) — the three-state read the procedure consts already carry, built ONCE in Storage beside the hourly builder: MAX(sample_interval_seconds) per collection (a readmitted plan stores 0 beside its siblings' real interval and contributes 0 to the sums, so MAX is the measured interval and is 0 only when EVERY row was unknowable), NULLIF(…, 0) so a restart collection is UNRATED, and the LAG only for a pre-V128 collection whose MAX is NULL. COALESCE(NULLIF(sample_interval_seconds, 0), LAG) is pinned by absence — it would fall back to a fabricated interval on precisely the restart row. The viewer's QueryDurationTrendSql is now the builder's output with its $4 filter (static readonly, like its hourly twin); its ExecutionCountTrendSql reads the interval the same way; Lite's GetQueryDurationTrendAsync and GetExecutionCountTrendAsync move to the same shape over v_query_stats. The builder's procedure output is pinned line-equal to both hand-kept procedure consts, so it is provably the established idiom and a later alias of those consts is a no-op.

Out of scope, and said so in the code: both SKUs' Query Store trends keep their LAG — no interval column on the source (a <para> on Lite's read and the rated CTE state why). Lite's LocalDataService.QueryStats.cs:592 COALESCE(sample_interval_seconds, LAG) is a history-grid display column, not a divisor, and COALESCE keeps a stored 0 as 0 (only NULL is replaced) — correct for the three-state rule, not a bug.

A brief claim found false, and the residual it leaves: DarlingTrendReader.QueryDurationTrendSql is NOT an alias of DurationTrendRouting — #3684 aliased the hourly SQL and the tier ladder; the raw query-stats const is its own LAG-only text in DarlingTrendReader.cs, a file outside this lane's boundary. It is not edited here. DarlingMcpTrendToolsTests names it as the residual with a must-move pin (DoesNotContain("sample_interval_seconds") on that const), so the one-line follow-up — public static readonly string QueryDurationTrendSql = DurationTrendRouting.QueryDurationTrendRawSql(withDatabaseFilter: false) — cannot land without touching the record of why. Until it lands, the MCP get_query_duration_trend raw route and the viewer's chart differ on exactly one row class: a restart collection (MCP 0.00, viewer unrated).

C. Compose averaged the restart marker in as a measured zero (ComposeCompiler)

For a MeasureArchetype.Cumulative measure the compiler aggregated DeltaColumn with no row predicate, so a restart row's (delta 0, interval 0) marker — "nothing knowable", per the #2234 contract — was averaged in as a measured zero and became the window's MIN every time a restart sat inside it. SUM was indifferent (adding 0). All ten delta families carry sample_interval_seconds since V128, so the compiler can say it once.

The shape — the aggregate's own FILTER, not the statement's WHERE. CAST(AVG(f.delta_wait_time_ms) FILTER (WHERE f.sample_interval_seconds IS DISTINCT FROM 0) AS double precision) for every raw-tier SUM/AVG/MIN/MAX whose column is a per-interval delta on a source the delta calculator stamps. The brief suggested the compiled WHERE; the overlay (#1606) is why not: one statement aggregates its primary and its overlay over the SAME rows, and memory_grant_stats carries a Cumulative (grant_timeouts) beside a Gauge (grant_waiters) — a WHERE would drop the restart row's real waiter reading along with the delta's marker, and a Gauge primary beside a Cumulative overlay would filter neither. The FILTER is scoped to the one aggregate the marker poisons, binds nothing (the $n order is untouched), and the RankedTimeSeries rank CTE inherits it through the same expression builder so membership is ranked over measured rows.

Which measures. "Carries the column" is CollectorDeltaCalculator.IsDeltaFamily(measure.SourceTable) — the ten-collector set DeltaFamilyIntervalColumnTests pins in both directions — not a second list that could drift. That covers the 25 Cumulative measures AND the two Delta-archetype measures on the same tables (wait_time_delta_ms, perfmon_value_delta): wait_time_delta_ms compiles to the very column wait_time_ms does, and filtering one name and not the other would have two names for one column disagree about one row. Query Store's qs_executions (Delta on a table without the column) compiles unfiltered, as it must — naming an absent column fails at parse time. Gauges, PerEvent columns, ratios, COUNT(*) and the CAGG route are untouched.

What this PR does NOT do

• Does not touch DarlingTrendReader.cs (the MCP raw query-stats const stays LAG-only; residual named above), TimescaleSupport.cs (no CAGG change — the A6 lane's), DarlingMcpTrendTools.cs (payload shape unchanged; its get_query_store_duration_trend description's clause "the window's first point … carries null rates" is now true only when that point is a raw point — a one-line follow-up on that file), or CHANGELOG.md.
• Does not give the raw Query Store arms an interval (no column to read).
• Does not filter Compose COUNT(*), gauges, ratios, or the CAGG route; does not alter Delta-archetype semantics on query_store_stats.
• Does not close Brains-review campaign: deferred structural residue (from #3538 / #3539 / #3540 / #3541) #3653.

Tests

Executed here (mactest pattern: the built Darling.Tests.dll run in-process with the WindowsDesktop framework entry removed; a net10.0-windows throwaway for the Lite DuckDB class; a throwaway timescale/timescaledb:2.28.1-pg18 on Docker as DARLING_TEST_PG):

• QueryStoreTrendRoutingTests (12/12) — new RollupTrendSql_RatesRollupPointsOverTheBucketWidth_AndRawPointsOverTheirSpacing: the class-gated CASE, the literal bound to HourlyBucketSecondsSql, the bare every-point LAG pinned by absence.
• QueryStoreTrendRoutingLiveTests (2/2, live TimescaleDB) — the existing test with its first-bucket pin MOVED (21 / 3,600, was unrated); new DurationTrend_AQuietHourDoesNotHalveTheNextBucketsRate: planted 10:00 / quiet 11:00 / 12:00 / raw 13:00 — rollup route 25 / 3,600, raw-only route 25 / 7,200 (the residual), MCP payload unrated_points = 0.
• DeltaFamilyIntervalCompletionLivePostgresTests (3/3, live PG) — new query-stats twin: viewer duration + execution-count reads and the builder text run raw, rows in all three states (NULL/NULL/0/120 + a readmitted-plan 0): 2.0 (LAG), unrated (restart), 10.0 (stored 120, not the LAG's 4.0).
• ViewerQueriesRestLivePostgresTests (4/4) — one pin MOVED: both seeded rows carried a stored 60 s, so both collections are rated (1.0 then 2.0 ms/sec); the single-point expectation was the LAG idiom applied to a row whose interval the store had.
• DarlingMcpTrendToolsSurfaceAndSqlTests (43/43) — the "reported, not rewritten" pin retired into RawDurationTrendSql_ReadsTheStoredInterval_ThreeState_AndTheProcedureConstsAreItsIdiom (builder ≡ viewer const; builder ≡ both procedure consts line-trimmed; the MCP const's must-move residual pin).
• McpZeroIsAMeasurementTests (20/20) — Lite census regex widened to the three-state END AS interval_seconds shape; Lite's three delta trends pinned three-state, Query Store pinned LAG-only.
• ViewerQueryTrendsSqlTests (11/11), DatabaseFilterTests (29/29), DurationTrendTierRoutingTests, DarlingPerformanceTrendsTierRoutingLiveTests, DarlingMcpTrendToolsLivePostgresTests, DarlingTrendEmptyTests — green.
• DarlingComposeTests (280/280) — new: per-archetype FILTER theory (8 cases incl. both Delta measures), non-delta absence theory (gauge/PerEvent/COUNT/qs_executions), ratio absence, overlay-in-either-position, rank-CTE, and a catalog-wide census gated on the real payload schema (27 filtered today; CAGG route asserted clean). DarlingComposeLivePostgresTests, ComposeQueryStoreLivePostgresTests, ComposeTopSeriesLivePostgresTests, ComposeAdHocModuleLivePostgresTests (5/5, live PG — the FILTER text executes), ComposeCaggValueMapperTests, ComposeParameterCoverageTests — green.
• Lite DeltaFamilyUnknowableRowReadTests — new QueryDurationTrend_… and ExecutionCountTrend_… (in-process DuckDB, same four-collection fixture as the procedure test): green; 10/11 in the class here, the one red is a PresentationFramework load on a pre-existing WPF-touching test (Mac artifact).
• psql on the rig, the builder's exact text: NULL, 2.0/0.1, NULL, 10.0/0.2; the FILTER on the same rows: AVG 380,000 → 633,333, MIN 0 → 100,000, SUM unchanged.

First executed in CI: ViewerTrendRoutingPortTests (two WPF-describer tests cannot load here; unchanged by this PR), the rest of Lite.Tests. Builds: Storage, Service, Viewer, Lite, Darling.Tests, Lite.Tests — -c Release -p:EnableWindowsTargeting=true, 0 warnings each (Lite.Tests carries one pre-existing xUnit2000 on dev in LogTailOverlapThresholdPinTests.cs, not touched).

Refs #3653 (partial — items A8 rollup denominators, A11's LAG-recompute clause, Compose Cumulative archetype). Review-dark window: auto-merge NOT armed; self-review in the lane report.

Which component(s) does this affect?

• Lite
• Darling
• Lite Tests
• Darling Tests
• SQL collection scripts
• Documentation
• Full Dashboard (deprecated)
• CLI Installer (deprecated)

How was this tested?

See Tests above: executed here on PG 18.4 / TimescaleDB 2.28.1 (throwaway container) and in-process DuckDB; no SQL Server involved (store-side reads only).

Checklist

• I have read the contributing guide
• My code builds with zero warnings (dotnet build -c Release -p:EnableWindowsTargeting=true)
• I have tested my changes against at least one store (PostgreSQL 18.4 + TimescaleDB 2.28.1; DuckDB in-process)
• I have not introduced any hardcoded credentials or server names