Analysis latest-value reads look back a day instead of scanning a server's whole history, and stop counting dropped databases (#3896)

[erikdarlingdata]

Closes #3896.

Why

The analysis "latest value" reads took each series' newest row with an upper time bound only, or no bound at all. They are the database-size, percent-autogrowth, disk-space, memory-clerk, plan-cache and memory_stats facts, plus the autogrowth drill-down. The window function numbered every row the server had retained to keep a few dozen, and TimescaleDB could exclude no chunk. On Lite, where the v_ views union the parquet archive, nothing could prune a row group.

The answer was also wrong. "Latest ever" kept a dropped database's files in DATABASE_TOTAL_SIZE_MB until retention aged them out. The same files, each with an ALTER DATABASE for a database that no longer exists, stayed in the autogrowth drill-down. Erik's production note stands: on the largest store DatabaseSizeSql is about a tenth of analyze_server, and PlanRegressionSql (#3902) dominates. This fix is the correctness half plus that tenth.

The diagnosis is confirmed and extended by one read. DB_CONFIG counted the same five dropped databases on DARLING01: 12 databases per-database-latest against 7 in the newest capture.

What changes

• The lookback. AnalysisContext.LatestValueLookback is 24 h, and LatestValueStart is the window end minus that. Anchoring on the window's end means an anchored or historical window reads the state as it stood then. A day clears every cadence these collectors run at by a wide margin; the slowest is database_size_stats, hourly.
• Seven reads bind it, as collection_time >= $2 AND collection_time <= $3 in all three SKUs. Darling: DatabaseSizeSql, FileAutogrowthSql, DiskSpaceSql, MemoryClerkSql, PlanCacheStatsSql, MemoryStatsSql and PgDrillDownCollector.AutogrowthPercentFilesSql, each with a byte-identical Lite twin. The Dashboard binds @lookbackStart on its six equivalents; it has no plan-cache read. MemoryStatsSql wasn't in the issue's inventory, but it has the same shape. On Lite its ORDER BY ... LIMIT 1 can't stop early across hot UNION parquet, so it sorted the whole archive.
• DB_CONFIG anchors on the newest capture (capture_time = MAX(capture_time)), which is the rule its drill-down ConfigIssuesSql already used. It takes no lookback, because database_config is an on-load snapshot and its newest capture is as old as the last connect.
• Behavior change, which the issue asked for: a series with no sample within a day of the window's end yields no fact, where it used to yield a stale one. DB_CONFIG stays present. The audit_config comments in both SKUs say so.
• Left unbounded on purpose. ServerConfigSql, TraceFlagsSql, ServerMetadataSql and ServerPropertiesSql read on-load snapshots. PlanHandleLookupSql is an indexed per-hash lookup: 0.07 ms, 15 ms at worst.

Test plan

• DARLING01 before/after (SQL2022, 17 days, 18 chunks, 16 compressed; EXPLAIN (ANALYZE, BUFFERS) via EXECUTE, warm). Results are identical except the ghost rows:

  read	before	after
  DatabaseSizeSql	1,167 ms, 571,576 rows into the window, 11,184 buffers	56 ms, 33,750 rows, 3,189 buffers
  result	239,067.90 MB (37 files)	182,495.64 MB (27 files; the 10 extra were 5 dropped DBs)
  MemoryClerkSql	129 ms (114,068 rows)	7.4 ms
  AutogrowthPercentFilesSql	10.2 ms	0.7 ms
  DiskSpaceSql	9.0 ms	0.9 ms
  FileAutogrowthSql	8.5 ms	0.6 ms
  PlanCacheStatsSql	0.9 ms (plan 1.5 ms)	0.9 ms (plan 0.3 ms)
  MemoryStatsSql	0.09 ms (plan 1.4 ms)	0.02 ms (plan 0.3 ms)

  That comes to roughly 1.31 s → 66 ms per fact pass, twice per compare_analysis. The deployed (pre-fix) get_analysis_facts on SQL2022 still reports DATABASE_TOTAL_SIZE_MB = 239067.9 through MCP.

• Lite before/after (DuckDB 1.5.5, synthetic: 100 files, 1-minute cadence, 23 days in parquet plus 7 hot, DatabaseSizeSql): 4,320,000 rows / 47 ms → 143,900 rows / 11 ms. The parquet arm becomes EMPTY_RESULT, because DuckDB prunes the archive on the bound parameter.

• New LatestValueLookbackTests (Darling, 27). SQL-shape pins for all seven reads. A scan over PgFactCollector.AllSql that fails any future newest-per-series read of a cadenced collector with no lower bound, with its own positive controls. The Lite twin pinned to the same text. The DB_CONFIG anchor.

  • Live on the rig: a live server reports only what it still has, and its drill-down lists the same file. A server whose newest sample is 25 h old emits none of the latest-value facts but keeps DB_CONFIG. A historical window reads the state at its own end, ghost included.
  • Plan shape: on hypertables, the shipped read plans ≤ 2 chunks where the pre-Analysis 'latest value' reads scan a server's entire retained history: half of every analyze_server call, and the database-size fact counts dropped databases (all three SKUs) #3896 oracle plans all 11.

• New Lite LatestValueLookbackTests (4). The same three scenarios on DuckDB, plus the Lite Recommendations never passes 24h warm-up after DuckDB archive/reset #1809 reset shape: everything in parquet, the ghost not counted, the live series archived minutes ago still counted.

• New Dashboard LatestValueLookbackSqlTests (7), source-text pins, since the Dashboard has no test DB.

• Red-watch: with the production SQL reverted, 21/27 Darling, 4/4 Lite and 7/7 Dashboard fail. The rest are the scanner's positive controls and the constant pin.

• Full Darling.Tests with DARLING_TEST_PG (rig: PostgreSQL 18.4 + TimescaleDB 2.28.1): 12,482 total, 0 failed, 21 skipped (PGRUNTIME/SQL-gated).

• Full Lite.Tests: 5,128, 0 failed. An earlier run made concurrently with the Darling suite hit StatusBarSizeReadLockTests and AnalysisPassTokenThreadingTests ("write lock never acquired", the static-lock contention family). Both pass alone and in a clean full run.

• Full Dashboard.Tests: 813, 0 failed. All builds show 0 warnings.

Found alongside and filed rather than folded in:

• PostgreSQL-target config reads plan every retained pg_server_config chunk: seconds per read once a store holds a year of snapshots #3928: the PostgreSQL-target config reads plan every retained pg_server_config chunk (365-day retention). That's 7 ms at 16 chunks, but 2.5-4.9 s per read at 366 chunks on the CI-sized rig. Posture and Clock need a ruling.
• TRACE_FLAGS keeps reporting a trace flag for weeks after it is turned off #3929: TRACE_FLAGS keeps reporting a flag after it's turned off, and anchoring doesn't fix it.
• A Darling server connected for more than 30 days loses its config facts: on-load snapshots age out and nothing re-collects them #3930: on-load config snapshots age out after 30 days of continuous connection.

🤖 Generated with Claude Code

https://claude.ai/code/session_018Z4T51J4E6L8fjriPHpsif