PostgreSQL 18 completa um ano: veja como testar o I/O assíncrono antes de ir para produção

O PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → 18 foi lançado em 25 de setembro de 2025, segundo as release notes oficiais do projeto. Faz um ano exato, e a comunidade já está discutindo o PostgreSQL 19 (a versão 19 Beta 4 saiu no dia 24 de setembro de 2026). Mas para quem ainda não migrou, ou migrou e nunca tocou nos parâmetros novos, vale voltar no item que mais importa para quem sofre com I/O em produção: o subsistema de I/O assíncrono (AIO), controlado pelo parâmetro io_method.

Antes do Postgres 18, todo backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → que precisava ler uma página do disco fazia isso de forma síncrona: pedia o bloco, bloqueava, esperava o kernel responder, seguia. Em sequential scan, bitmap heap scan e vacuum, isso significa uma fila de pedidos de leitura processados um a um, mesmo quando o storage subjacente (SSD NVMe, EBS, disco em RAID) aguentaria várias requisições em paralelo sem problema. O resultado clássico: CPU ociosa enquanto o processo espera I/O, e vacuum que demora horas num storage que tecnicamente tem banda de sobra.

O que o AIO realmente muda

Segundo as release notes, o novo subsistema "permite que backends enfileirem múltiplos pedidos de leitura", o que torna sequential scans, bitmap heap scans e vacuums mais eficientes. Isso é diferente de paralelismo de query (que já existia): aqui o ganho é dentro de um único processo, que passa a poder disparar várias leituras de disco antes de precisar que a primeira termine, em vez de serializar tudo.

A mudança prática mais visível para quem administra banco: os parâmetros effective_io_concurrency e maintenance_io_concurrency passaram a valer também em sistemas sem suporte a fadvise(), e o valor padrão de ambos subiu para 16 (antes era mais conservador). Isso já reflete a expectativa de hardware moderno com fila de I/O mais funda que um disco rotacional de 2010.

Os três modos de io_method e seus trade-offs

O comportamento do AIO é controlado pela GUC io_method. As release notes confirmam que o parâmetro existe e que ele, junto com io_combine_limit e io_max_combine_limit, controla como o subsistema assíncrono enfileira as leituras, mas não detalham quais valores o parâmetro aceita, qual é o padrão de fábrica nem os requisitos específicos de sistema operacional ou de compilação para cada opção. Antes de trocar esse parâmetro em produção, vale checar a documentação de configuração da sua versão para confirmar esses pontos: cada valor tem implicações diferentes de portabilidade e desempenho, e escolher o valor errado pode não trazer o ganho esperado (ou nem funcionar, dependendo do ambiente).

Não existe modo "certo" universal: a escolha depende do sistema operacional, da versão do kernel e de como o binário do Postgres foi compilado, então vale testar mais de uma opção na sua carga real antes de decidir qual fica em produção.

Como testar antes de trocar em produção

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

O caminho recomendado é isolar a mudança num ambiente de staging com carga real (ou o mais próximo disso) antes de tocar no cluster de produção:

-- ver o modo atual
SHOW io_method;

-- trocar (consulte a documentação de configuração do parâmetro para confirmar
-- os valores aceitos e se a mudança exige reinício do servidor; as release
-- notes usadas nesta reportagem não listam os valores válidos)
ALTER SYSTEM SET io_method = '<valor confirmado na documentação da sua versão>';

Após reiniciar, o Postgres 18 expõe uma view nova, pg_aios, que mostra os file handles em uso pelo subsistema assíncrono:

SELECT * FROM pg_aios;

Para enxergar o efeito em volume de dados, o jeito mais direto é olhar pg_stat_io, que ganhou colunas novas nesta versão: read_bytes, write_bytes e extend_bytes (a coluna antiga op_bytes, que sempre valia BLCKSZ, foi removida). Rodar um VACUUM VERBOSE numa tabela grande e comparar o tempo total entre valores diferentes de io_method dá um indicador concreto de ganho antes de aplicar em produção, junto com as novas colunas de tempo em pg_stat_all_tables (total_vacuum_time, total_autovacuum_time, total_analyze_time, total_autoanalyze_time), que ajudam a medir se o vacuum realmente ficou mais rápido sem precisar instrumentar nada externo.

Vale também ajustar io_combine_limit e io_max_combine_limit, os dois parâmetros que controlam quantas leituras o Postgres tenta agrupar numa única requisição de I/O maior. Aumentar esses limites tende a ajudar em storage com boa banda sequencial (SSD NVMe), mas em storage com latência alta por operação (alguns cenários de rede, como certos volumes de rede em nuvem) o ganho pode ser marginal ou até negativo se o combine ficar agressivo demais para o padrão de acesso da carga.

Quando não vale a pena mexer agora

Se o cluster já roda com o io_method padrão de fábrica e a aplicação não sente gargalo perceptível de disco, trocar esse parâmetro sem medir antes é risco desnecessário. Antes de trocar de valor, vale checar na documentação oficial do parâmetro quais opções existem, qual é o padrão da sua versão e os requisitos de sistema operacional ou de compilação de cada uma; as release notes usadas nesta reportagem não detalham esses pontos. Vale investigar alternativas só se o workload tiver volume de leitura sequencial ou vacuum pesado o suficiente para o ganho aparecer nas métricas de pg_stat_io. Em bancos pequenos, com working set que cabe inteiro em shared_buffers, o AIO simplesmente não tem I/O de disco relevante para acelerar, e o esforço de validar um io_method diferente não compensa.

O ponto prático: quem já mantém Postgres em produção há anos aprendeu a desconfiar de qualquer GUC nova que promete performance de graça. O AIO do Postgres 18 é uma mudança de arquitetura real, não um ajuste cosmético, e por isso merece o mesmo tratamento de qualquer mudança de storage engine: medir em staging com pg_aios e pg_stat_io ligados, comparar os modos disponíveis na carga real do seu sistema, e só então decidir qual io_method fica no postgresql.conf de produção.

Fonte: PostgreSQL 18 Release Notes