Graham McIntire
03c91f4098
Two issues spotted in pg_stat_user_tables: 1. Most `hrrr_profiles` partitions have `last_autoanalyze IS NULL`. The partitions are append-only from the hourly grid worker, so autovacuum never crosses the analyze threshold — but without stats the planner falls back to estimates and picks bad joins on per-QSO lookups. 2. `contacts`, `grid_tasks`, `hrrr_fetch_tasks`, and `contact_common_volume_radar` see high UPDATE volumes (enrichment status flips, queue claim/complete cycles, mechanism classifier writes) but only accrue ~5% dead before the default 20% / 10% autovacuum triggers fire. BackfillEnqueueWorker's status-priority ORDER BY + the Rust workers' FOR UPDATE SKIP LOCKED claim scan both want fresher stats than that. Changes: - Migration `20260424204656_tune_autovacuum_for_high_churn` sets per-table `autovacuum_*_scale_factor` + `_threshold = 50` on the four tables above. Aggressive enough to keep stats current; tame enough that vacuum doesn't thrash the Turing Pi 2 Postgres node. Reversible. - `Weather.analyze_all/1` walks `pg_stat_user_tables`, runs `ANALYZE` on every table not auto-analyzed in the last 6 h, reports counts. Meant to be invoked once via `bin/microwaveprop rpc 'Microwaveprop.Weather.analyze_all()'` after deploy to seed statistics on the cold partitions; idempotent on re-run. |
||
|---|---|---|
| .. | ||
| microwaveprop | ||
| microwaveprop_web | ||
| mix/tasks | ||
| microwaveprop.ex | ||
| microwaveprop_web.ex | ||