Plan regression analysis falls back to the raw query_store_stats read on almost half its passes #5513

Claude posting for Erik Darling.

Found by the #5508 audit. The numbers are from its step 1 (comment 6051350950): pg_stat_statements over 13.2 days on a store with 43 servers at schema V165. Line numbers are at dev 25f68ae.

What runs

CollectPlanRegressionFactsAsync (Darling/PerformanceMonitor.Darling.Analysis/PgFactCollector.QueryPerf.cs, about lines 660 to 720) picks one of two reads for the PLAN_REGRESSION fact.

• When QueryStoreIntervalLatest.ReadsTableAsync (Darling/PerformanceMonitor.Darling.Storage/QueryStoreIntervalLatest.cs:408) says the interval table covers the window, it reads the table.
• Otherwise it reads raw collect.query_store_stats with PlanRegressionSql (QueryPerf.cs:312).

Numbers

• The raw read ran 12,510 times, under two statement ids with the same text.
• It read 605 M blocks and ran for 99,159 s, about 27.5 hours. That is 47,586 and 51,341 blocks per call.
• The table read ran 14,866 times. So about 46% of passes took the raw path.

Why it matters

#5507 and the V168 per-day totals make the table path cheaper. Neither touches the raw path.

Not yet known

Why ReadsTableAsync returns false this often. Candidates are coverage that starts after the window's start, a pending coverage row, or a server that was never backfilled. This is inferred from the code, not observed.

Fix direction

Find the cause first, with a read-only query on the coverage rows. Then fill the coverage, or let the table serve the days it covers and read raw rows only for the rest. Code only. No schema rung is expected.