Store rung V152: drop the Query Store rollups' unread group indexes

[erikdarlingdata]

Refs #4503.

Why

On one production store, the Query Store rollups' refreshes wrote ~30% of the store's WAL over ~71 hours, and most of it went into indexes nothing reads.

• The indexes: TimescaleDB creates a "group" index (column, bucket DESC) on a continuous aggregate's materialization hypertable for every GROUP BY column, unless the aggregate says timescaledb.create_group_indexes = false.
  • query_store_stats_hourly, _corrected_hourly, _daily, _corrected_daily and _daygrain_daily each carry 5 (database_name, module_name, query_hash, server_id, server_name).
  • query_store_stats_interval_daily carries 11 (~10.9 GB). It wrote 34 GB of WAL in 3 refreshes.
• Their reads: idx_scan summed over each index's chunks, over the store's lifetime, is 0 on the real chunks for every group index except server_id (and server_name on one hourly rollup: 131).
  • One empty 8 KB chunk on each hourly rollup shows scans on its database_name index (1,498 and 1,976), and the same pattern on server_id (5,397 and 2,848). On an empty chunk every index costs the same, so which one the planner picks there says nothing. The likely source is the trend read's optional database filter.
• The precedent: Alert reads die during the interval-hourly Query Store refresh: 26/26 runs over four minutes, 417 s average, breathing with load — the grid protects writers from locks, nothing protects readers from I/O #3597 measured 4.3× the WAL from these indexes on query_store_stats_interval_hourly, and turned them off there only.

What changes

• Store rung V152 drops the unread group indexes on the six rollups. It keeps each one's bucket index and (server_id, bucket DESC), plus (server_name, bucket DESC) on the two hourly rollups.
  • Matched by key columns through the catalog (pg_index / pg_attribute on the materialization hypertable resolved from the view), never by a built name. PostgreSQL truncates identifiers at 63 bytes, so …_runtime_stats_interval_id_bucket_idx doesn't exist under that name, and a name-based DROP INDEX IF EXISTS would silently keep it.
  • It's idempotent, and skips a rollup that doesn't exist.
• Fresh stores match upgraded ones exactly. The six rollups are created with timescaledb.create_group_indexes = false, then the kept indexes are created unnamed ON the rollup as (column, bucket DESC). That gives PostgreSQL's default name, which is TimescaleDB's own form, so a fresh store's indexes are byte-identical to an upgraded store's.
• The readers and the index each one uses after V152 (every non-test reader of the six rollups):

reader	rollup	filter	index after V152
QueryStoreTrendRouting.BuildRollupTrendSql (Viewer and MCP trend reads)	_corrected_hourly	server_id, bucket range, optional database_name	(server_id, bucket)
RollupBoundsSql	_corrected_hourly	min/max(bucket)	bucket
Composed panels (ComposeCompiler via ComposeSourceRouter)	the hourly and daily rollups and _daygrain_daily	bucket range; server_name only when the panel is scoped to servers; optional database, module or query hash filters	hourly: (server_name, bucket) or bucket; daily: bucket
Backfill and materialization-hole reads (RollupBackfill, MaterializationHoles)	all six	min/max(bucket)	bucket
none (it only feeds _daygrain_daily)	_interval_daily		(server_id, bucket) kept

• No reader filters a dropped column without a bucket range. The daily rollups' server_name index is dropped too: it showed 0 lifetime scans, so a scoped daily panel already runs on bucket plus a filter today.
• A composed panel that filters on a dropped column still returns the same rows, through the kept indexes.
• The Viewer's store probe recognises V152 by the absence of the hourly rollup's (query_hash, bucket) index AND V151's own marker. It walks the view's own dependency (pg_rewrite / pg_depend), so it needs no extension check, and it works as the viewer role. Requiring V151's marker keeps a store below V151 without the rollup from reading as V152. A plain-PostgreSQL store at V151 reads as V152, which is harmless: V152 does nothing without TimescaleDB, so the two schemas are identical.
• Without TimescaleDB, V152 does nothing and still records version 152 (there are no rollups to change).
• Locks: DROP INDEX on a hypertable locks it and every chunk, inside the rung's one transaction. V152 sets lock_timeout to the migration statement timeout minus 20 seconds (280 s today, derived from the same constant so the two can't cross), long enough to wait out a running hourly rollup refresh (about 264 s). During a one-time upgrade start that lands on a running rollup refresh, Query Store trend reads can wait up to ~4.5 minutes, and collection starts after the upgrade finishes. The 120-second start retry budget only decides whether to start another attempt; it never cancels one in flight.
• The drop skips UNIQUE indexes and indexes with INCLUDE columns, so an index an operator added on the same columns is left alone.
• One test guard is relaxed: MigrationDataMovingRungCensusPins.TheLadderStillContainsNoDynamicSql now exempts V152 (and only V152, through a named list with its reason). V152's DROP INDEX has to be built at runtime, because the index names differ per store. The census exists to account for data-moving DDL against the migration lock budget, and a DROP INDEX moves no data.
• Lite has no continuous aggregates, so there's no Lite twin.

Test plan

In-process on macOS against a live PostgreSQL 18 + TimescaleDB 2.30.

• CaggGroupIndexDropLiveTests:
  • (a) after a fresh migrate, each of the six rollups has exactly the kept indexes (matched by key columns) and none of the dropped ones. RED at runtime on dev.
  • (c) V152 run twice leaves the same pg_indexes rows.
• CaggGroupIndexDropUpgradeLiveTests: a store at V151 with the six rollups materialized and compressed.
  • Every reader query's rows are captured, V152 runs, and the rows are captured again. The rows are identical (ordered), and the index assertions hold.
  • The readers: BuildRollupTrendSql with and without the database filter, RollupBoundsSql, and a server + bucket + database read per rollup.
  • RED at runtime on dev.
• A mutation: matching the drop by a built name instead of key columns → RED; the runtime_stats_interval_id index survives because of the 63-byte truncation.
• PgSchemaGeneratorTests: fresh vs upgraded, extended to these indexes.
• The rung: CaggGroupIndexDropRungTests (the new top rung: ladder, probe sentinel and arm), and AgGroupIdRungTests in the stays-true shape. The "zero every rung above me" loops pick up the new ordinal unchanged.
• Three pins widened for the new design: two TimescaleContinuousAggregateTests assertions expect the new WITH (…) clause, and IntervalDedupMaterializationIndexesTests now names the six rollups V152 measures. It still asserts every other aggregate keeps its default group indexes.
• Added since: V152_OnAStoreWithoutTimescaleDb_CompletesAsANoOp (RED before the extension guard); probe pins (a store at V150 without the rollup does not read as V152, a TimescaleDB store at V151 reads as V151, and the probe on a migrated store maps to this build); ARunningRollupRefreshHoldingTheMaterializationLockForEightSeconds_IsWaitedOut_AndTheMigrationReaches152 (RED at a 5 s lock timeout).
• Totals: the V152 set passes with TimescaleDB, and the fresh-database classes pass on a database without it. Darling.Tests and Lite.Tests build with 0 warnings.

Measurements

On the rig, 49,920 query_store_stats rows (10 servers × 24 hours × 208 queries), one hourly rollup of the same shape, refreshed over the day. WAL was measured by pg_wal_lsn_diff around the refresh, twice on independent windows:

	run 1	run 2
with the group indexes	32.0 MiB	31.9 MiB
without them	11.2 MiB	11.2 MiB
ratio	2.85×	2.84×

This is a rig number, for one rollup at a small fraction of production scale.

CHANGELOG

SECTION: Changed
ENTRY:

• The store writes much less WAL refreshing its Query Store rollups ([Store rung V152: drop the Query Store rollups' unread group indexes #4506]) - store rung V152 drops the rollups' automatically created group indexes that no reader uses, and keeps the time and server indexes the reads need.
  REF:
  [Store rung V152: drop the Query Store rollups' unread group indexes #4506]: Store rung V152: drop the Query Store rollups' unread group indexes #4506

IMPORTANT: Store rung V152 drops unused indexes on six Query Store rollups (no data changes; rows read the same before and after). During a one-time upgrade start that lands on a running rollup refresh, Query Store trend reads can wait up to ~4.5 minutes, and collection starts after the upgrade finishes.