Vacuum, autovacuum e bloat: causa #1 de DB morrendo

-- Tabelas com mais dead tuples
SELECT
  schemaname, relname,
  n_live_tup, n_dead_tup,
  ROUND(n_dead_tup::numeric / NULLIF(n_live_tup, 0) * 100, 2) AS dead_pct,
  last_autovacuum,
  last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

-- Extension pgstattuple (mais precisa)
CREATE EXTENSION pgstattuple;
SELECT * FROM pgstattuple('orders');
-- mostra tuple_count, dead_tuple_count, free_space, etc

-- Tabela hot (muitos updates): autovacuum mais agressivo
ALTER TABLE orders SET (
  autovacuum_vacuum_scale_factor = 0.05,   -- default 0.2
  autovacuum_analyze_scale_factor = 0.02,  -- default 0.1
  autovacuum_vacuum_cost_delay = 10        -- ms entre chunks
);

-- Desliga autovacuum em tabela static (append-only arquivo)
ALTER TABLE immutable_logs SET (autovacuum_enabled = false);

-- Monitor: não autovacuum em 1h+ com muitos dead?
SELECT relname, n_dead_tup, last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000 AND (last_autovacuum < now() - INTERVAL '1 hour' OR last_autovacuum IS NULL);

# Extensão + tool CLI (não built-in)
# Recria tabela sem lock exclusivo — trigger mantém consistência durante

pg_repack -h localhost -U postgres -d mydb -t orders

# Pré-requisitos: PRIMARY KEY, espaço em disk (cria cópia antes de swap)
# Alternativa: pg_squeeze (nativo PG13+ em algumas distros)