Store: re-measure a rollup's coverage floor only when its oldest chunk changes (#4539)

[erikdarlingdata]

Fixes #4539

Why

The rollup coverage probe re-runs min(bucket) against every present rollup's materialization on every cycle. On a compressed materialization chunk that sort touches every one of that chunk's compressed batches before it can decompress the first one — measured on a production store at roughly 170 MB of temp every five minutes, because the oldest Query Store rollup chunks hold tens of thousands of batches. The floor only actually moves when the rollup's oldest chunk changes (retention drops it, or an older backfill creates an earlier one), so re-sorting it on every cycle regardless is wasted work.

What changes

• A per-data-source cache (ConditionalWeakTable<NpgsqlDataSource, ...>) keyed on each rollup's oldest materialization chunk identity. A cheap catalog read (RollupOldestChunkSql) decides which rollups' chunk identity changed since the last cycle; only those get a fresh min(bucket), and the rest reuse their last-measured floor.
• RollupCoverageProbeSql gained an overload that takes the set of rollups to actually measure this cycle; a rollup not in that set contributes NULL::timestamp and is never named in the query, the same "don't mention an absent relation" trick already used for a rollup that doesn't exist at all. The existing one-argument overload (used by RetentionArmSafetySql and everything else) is unchanged and stays byte-identical.
• When a cached floor is used, and when it is not:
  • The floor merge is a pure function, MergeRollupFloors. A rollup measured this cycle always uses the measured value: if it comes back NULL (empty, or re-created with no data), it has no floor and its cache entry is dropped. Only rollups not measured this cycle reuse a cached floor.
  • The cache key is the oldest chunk's name AND the materialization hypertable's identity, so dropping and re-creating a rollup always forces a re-measure.
  • A cached floor is reused for at most one hour (RollupFloorMaxReuse). Nothing in this code deletes rows from a rollup's oldest chunk without dropping it, but a manual refresh over raw data that is already gone, or a manual DELETE, could move the true floor later without changing the chunk. The one-hour limit bounds how long such a change can go unseen, and still cuts the probe from every five minutes to at most once an hour.
  • A rollup that no longer exists has its cache entry dropped.
• A failed catalog read (a plain PostgreSQL store, or any other failure) falls back to measuring every present rollup, the same behavior as before this cache existed.

Test plan

Live end-to-end pin (RollupFloorCacheLiveTests) against a real TimescaleDB with a compressed materialization:

• (a) the first call's measured floor matches a fresh min(bucket).
• (b) a second call on the same data source returns the same floor. Counted through Npgsql's own "Executing command" debug log line for the min(bucket) probe against the materialization view: across both calls combined, exactly one such statement executes on this branch — RED on dev, run: Assert.Equal() Failure: Values differ. Expected: 1. Actual: 2. pg_stat_user_tables' seq_scan/idx_scan counters were tried first and measured unreliable on a compressed chunk (they don't change either way), and this rig doesn't preload pg_stat_statements.
• (c) after dropping the oldest materialization chunk, the next call re-measures and the floor moves later, tracking the true min(bucket).

Pure pins (RollupFloorCacheTests): a measured NULL with a cached entry evicts it; a rollup not measured this cycle reuses its entry; a rollup that no longer exists drops its entry; the same chunk name on a different materialization hypertable is measured; an entry older than the one-hour limit is measured, and one well under it is reused (an injectable clock, no sleep). A mutation that disables the measured-NULL eviction fails two of them.

IntervalHonestHourlyRollupLiveTests (drop and re-create a rollup with no data on the same data source; the coverage floor must read NULL) failed against the first version of this change and passes now.

A mutation of the pure planner (RollupFloorsToMeasure, dropping the chunk-identity comparison so a rollup is measured only once ever, regardless of a later chunk change) turned pin (c) RED (Expected: 2026-09-26 ... Actual: 2026-09-25 ...); reverting it returns to GREEN.

Ran on this Mac against a scratch TimescaleDB rig: RollupFloorCacheTests, RollupFloorCacheLiveTests, and every other class touching DetectRollupCoverageAsync/RollupCoverageProbeSql plus DocCommentHygieneTests. Total: 255, Failed: 0, Skipped: 3 (the 3 skips are pre-existing environment-gated live tests unrelated to this change). LivePostgresCollectionHygieneTests needs a Windows runtime and runs in CI.

Darling.Tests and Lite.Tests build clean (0 errors, 0 warnings) with -p:EnableWindowsTargeting=true; both target net10.0-windows and can't execute on macOS, so CI decides them for real.

Field effect (expected): on the production store that showed the spill, the coverage probe's two spilling min(bucket) reads stop running on every cycle. They run again only when a rollup's oldest materialization chunk changes (a retention drop), after an hour, or after a restart.

CHANGELOG

SECTION: Fixed
ENTRY: - The rollup coverage check no longer writes about 170 MB of temp files every five minutes on a large store ([#4553]) - Finding a rollup's oldest bucket sorts every compressed batch of its oldest chunk. The check now re-measures a rollup only when its oldest chunk changes, and reuses the last measurement otherwise.
REF: [#4553]: #4553