Stop query_stats from recording a false zero CPU when only the CPU delta is unknowable (#4394)

[erikdarlingdata]

Refs #4394.

Why

QueryStatsCollector.WritePayload makes eight independent delta calls per row, one per counter family, and keeps only the worker (CPU) call's interval as sample_interval_seconds. When the worker family's delta call takes the no-delta path (a first sighting, a counter reset, or a gap past the policy) it reports interval 0 — the honest signal for "this counter's delta is not knowable." But the exec-count and elapsed-time families are keyed and evaluated independently, and in the field they sometimes DO have a real, knowable delta in the same pass where CPU does not. The row was written with CPU 0 and sample_interval_seconds 0 regardless, and the interval-honest filter (sample_interval_seconds IS DISTINCT FROM 0) then discarded that row's real executions and elapsed duration along with the fabricated CPU zero.

Observed on two production SQL Server stores over 24 hours: 183 and 8,844 rows respectively (up to 0.43% of fleet-wide elapsed time), up to 100% of a rare query's day on one store, one row that carried up to 50 seconds of elapsed time, and on one store 86% of the affected rows showing zero reads with a long tail of nonzero ones.

What changes

• The exec-count and elapsed-time delta calls now capture their own intervals (execIntervalSeconds, elapsedIntervalSeconds) instead of discarding them with out _.
• A new pure helper, QueryStatsCollector.ResolveWorkerDelta, decides what to write for CPU and the row's sample_interval_seconds:
  • If the worker call's own interval is 0 (unknowable) AND either the exec or elapsed call returned a real interval, the row writes delta_worker_time as NULL and takes sample_interval_seconds from the exec interval (falling back to elapsed if exec is also 0).
  • Otherwise the worker call's own delta and interval pass through unchanged.
• A doc comment on the rule cites Raw top-N reads sum zero-interval first-collection rows that the interval-honest rollups exclude #4394 and get_perfmon_trend: delta_value returns a fabricated 0 on ~38% of points while cntr_value advances #2234's "interval 0 means no delta knowable" pairing, and states that the pairing now holds per counter instead of per row.

Not changed

• A real unchanged CPU counter keeps its 0. A worker delta of 0 over a REAL interval (e.g. a query that ran the whole window but burned no measurable CPU, such as one that spent it all blocked) is a measured zero, not an unknowable one, and is left untouched with its own real interval. This is pinned explicitly (WorkerZeroOverARealInterval_KeepsTheMeasuredZero).
• A row where every counter is unknowable (first sighting/reset/gap across the board) stays exactly as it is today: CPU 0, interval 0.
• The other five counters' deltas (reads, writes, physical reads, rows, spills) are untouched.
• Rows already written are not rewritten by this change.
• The per-database hourly continuous aggregate (query_stats_interval_hourly) still filters on sample_interval_seconds IS DISTINCT FROM 0, not on delta_worker_time, so a NULL-CPU row with a real interval is included in the rollup's executions/elapsed sums and simply skipped by sum()/min()/max() for the worker column — no continuous-aggregate change was needed or made.
• ICollectorRowWriter.Value(long?) already exists on both the PostgreSQL (Darling) and DuckDB (Lite) writers, and delta_worker_time is already nullable in both stores, so this needed no migration.

Test plan

• Pure helper (Darling/Darling.Tests/QueryStatsUnknownCpuTests.cs): five cases against ResolveWorkerDelta — worker unknown + exec known, worker+exec unknown + elapsed known, the stakeholder's real-zero case, all-unknown, and a normal delta. RED on dev: the helper doesn't exist there, so this is a compile-time RED (confirmed on a detached worktree at dev's tip, 15 compile errors, all CS0117/CS8130 pointing at the missing member).
• Through the collector's payload (same file, one more [Fact]): drives a real CollectorDeltaCalculator where the exec and elapsed families already know the row's key from a prior pass but the worker family sees it for the first time, and a recording ICollectorRowWriter. Asserts delta_worker_time is NULL and sample_interval_seconds comes from the exec interval. Included in the same RED-on-dev compile failure above.
• Live (Darling/Darling.Tests/QueryStatsUnknownCpuLiveTests.cs, own scratch database per #1776): after PgMigrations.MigrateAsync, plants one normal row and one NULL-CPU row (real interval, real executions/elapsed) for the same query hash, refreshes query_stats_interval_hourly, and asserts the hourly rollup's execution-count and elapsed sums include both rows while the worker sum equals the normal row alone. A second assertion runs the Viewer's worker_time_per_second expression (CAST(delta_worker_time AS double precision) / NULLIF(sample_interval_seconds, 0) / 1000.0) directly against both rows: it returns a number for the normal row and NULL — not an error — for the unknown one.
• Ran on this Mac against a throwaway timescale/timescaledb:2.30.1-pg18 container (removed after the run): all new tests green, plus the existing DeltaSeriesAgeTests class (25 total, 0 failures).
• Built Darling.Tests and Lite.Tests on macOS with EnableWindowsTargeting=true: 0 warnings/errors on both. Did not find an existing CollectorPayloadArityTests/QueryStatsCollectorDefinitionTests assertion that pins delta_worker_time's nullability or arity in a way this breaks; Lite.Tests built clean unmodified.
• Did not run the full existing Darling.Tests/Lite.Tests suites end to end given the time remaining in this pass — only the touched/related classes above. CI will run the full suites on Windows.

CHANGELOG entry

SECTION: Fixed
ENTRY:

• Query statistics no longer record a false zero CPU when only the CPU counter's delta is unknowable; those rows keep their executions and duration ([Stop query_stats from recording a false zero CPU when only the CPU delta is unknowable (#4394) #4423]) - a query_stats row whose CPU (worker time) counter reset or was seen for the first time, while its execution-count or elapsed-time counters had a real delta in the same pass, previously wrote CPU as a false 0 over a fabricated zero interval — which then caused the row's real executions and duration to be dropped by the interval-honest filter along with the fake CPU. That row now records CPU as unknown (NULL) and keeps its real interval, executions, and duration. A CPU counter that is genuinely unchanged over a real measured interval still records 0, unchanged.

REF:
[#4423]: #4423