Tuning automatizado do PostgreSQL: como o workload muda cada recomendação

Tuning automatizado só é útil quando entende o workload. O mesmo valor de work_mem pode ser conservador em um ambiente analítico com poucas sessões e perigoso em um OLTP com centenas de operações concorrentes. Antes de recomendar parâmetros, é preciso classificar como o PostgreSQL realmente está sendo usado.

O risco do tuning PostgreSQL genérico

Listas prontas normalmente começam com percentuais de RAM e terminam sem medir queries, concorrência, arquivos temporários, WAL ou latência de disco. Esses valores podem servir como ponto inicial de laboratório, mas não provam que uma mudança é segura em produção.

• shared_buffers compete com o page cache do sistema operacional.
• work_mem pode ser usado várias vezes pela mesma query e por workers paralelos.
• max_connections representa um teto, não a simultaneidade desejável.
• WAL e checkpoints precisam respeitar capacidade de disco e objetivo de recuperação.

OLTP e OLAP pedem decisões diferentes

Workload OLTP

• Muitas transações curtas e alta concorrência.
• Sensibilidade a locks, conexões e latência por operação.
• Índices seletivos e queries previsíveis são fundamentais.
• work_mem global precisa ser conservador.

Workload OLAP

• Menos consultas, porém com scans, joins, sorts e hashes maiores.
• Maior oportunidade para paralelismo e memória por sessão controlada.
• Throughput do relatório pode importar mais que latência transacional.
• Particionamento, estatísticas e I/O têm peso maior.

Ambientes reais costumam ser híbridos. Um sistema OLTP pode receber relatórios pesados durante o expediente; nesse caso, valores por role ou sessão são frequentemente mais seguros que uma elevação global.

Quais sinais classificam o workload

A classificação deve usar séries históricas, não uma fotografia. Entre os sinais úteis estão:

• duração, chamadas e tempo total por fingerprint em pg_stat_statements;
• relações entre commits, inserts, updates, deletes e leituras;
• conexões ativas, waits, locks e transações longas;
• arquivos temporários, operações paralelas e spill para disco;
• taxa de WAL, checkpoints, autovacuum e comportamento por tabela;
• CPU, memória e latência de armazenamento no mesmo intervalo.

Como transformar classificação em recomendação

Uma recomendação responsável precisa informar valor atual, mudança sugerida, evidência, impacto esperado, risco, contexto do parâmetro e forma de validação. Também deve distinguir parâmetros que aceitam reload daqueles que exigem restart.

Parâmetro: work_mem
Hipótese: sorts relevantes estão gravando arquivos temporários
Escopo inicial: role de relatórios, não valor global
Evidência: temp_blks_written + EXPLAIN do workload
Validação: p95, temp bytes, memória e concorrência
Rollback: restaurar valor anterior da role

Por que work_mem exige contexto de concorrência

Dividir memória por max_connections ignora o número de operações e workers. Um orçamento mais útil estima queries pesadas simultâneas, operações de sort ou hash por query e paralelismo. Mesmo assim, o resultado é um limite inicial que precisa ser validado sob carga.

Use o Configuration Planner para modelar esses fatores e consulte o guia completo de tuning PostgreSQL para o processo de baseline, teste e rollback.

Automação deve recomendar, não esconder risco

Uma ferramenta pode reduzir o trabalho de correlacionar métricas, mas não deve aplicar mudanças críticas sem revisão. Deploy recente, incidente aberto, pressão de conexão, pouca folga de disco ou ausência de baseline são motivos para adiar uma alteração aparentemente correta.

O PG Monitoring classifica padrões de carga e apresenta recomendações de configuração junto com sinais operacionais. A decisão final continua revisável: a equipe vê a evidência, avalia a janela e confirma como medir o resultado.

Próximo passo

Se o problema é recorrente, monitore o workload ao longo do tempo. Se a produção já está degradada e exige correlação entre queries, planos, configuração e infraestrutura, conheça a consultoria de tuning PostgreSQL no Brasil.