Otimizador de Egress do Postgres

Quando Usar

Use esta habilidade quando precisar diagnosticar e corrigir o tráfego de saída excessivo do Postgres (transferência de dados de rede) em uma base de código. Use quando um usuário mencionar contas de banco de dados altas, custos inesperados de transferência de dados, cobranças de transferência de rede, picos de saída, "por que minha conta Neon está tão alta", "os custos do banco de dados dispararam", otimização de SELECT *, consulta...

Oriente o usuário no diagnóstico e correção de padrões de consulta do lado da aplicação que causam transferência excessiva de dados (saída) do banco de dados Postgres. A maioria das contas de saída altas vem da aplicação buscando mais dados do que utiliza.

Passo 1: Diagnosticar

Identifique quais consultas transferem mais dados. A ferramenta principal é a extensão pg_stat_statements.

Verificar se pg_stat_statements está disponível

SELECT 1 FROM pg_stat_statements LIMIT 1;

Se isso gerar um erro, a extensão precisa ser criada:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

No Neon, ela está disponível por padrão, mas pode precisar desta etapa CREATE EXTENSION.

Lidar com estatísticas vazias

As estatísticas são limpas quando um compute Neon escala para zero e reinicia. Se as estatísticas estiverem vazias ou o compute acordou recentemente:

1. Reinicie as estatísticas para iniciar uma janela de medição limpa: SELECT pg_stat_statements_reset();
2. Deixe a aplicação rodar sob tráfego representativo por pelo menos uma hora.
3. Retorne e execute as consultas de diagnóstico abaixo.

Se o usuário tiver estatísticas de um banco de dados de produção, use-as. Se ele não tiver acesso às estatísticas de produção, prossiga para o Passo 2 e analise a base de código diretamente — padrões de nível de código geralmente são suficientes para identificar os piores infratores.

Consultas de diagnóstico

Execute estas para identificar os principais contribuintes de saída. Concentre-se em consultas que retornam muitas linhas, retornam linhas largas (colunas JSONB, TEXT, BYTEA) ou são chamadas com muita frequência.

Consultas retornando o maior número total de linhas:

SELECT query, calls, rows AS total_rows, rows / calls AS avg_rows_per_call
FROM pg_stat_statements
WHERE calls > 0
ORDER BY rows DESC
LIMIT 10;

Consultas retornando o maior número de linhas por execução (SELECTs mal escopados, paginação ausente):

SELECT query, calls, rows AS total_rows, rows / calls AS avg_rows_per_call
FROM pg_stat_statements
WHERE calls > 0
ORDER BY avg_rows_per_call DESC
LIMIT 10;

Consultas chamadas com mais frequência (candidatas para cache):

SELECT query, calls, rows AS total_rows, rows / calls AS avg_rows_per_call
FROM pg_stat_statements
WHERE calls > 0
ORDER BY calls DESC
LIMIT 10;

Consultas de execução mais longa (não é uma medida direta de saída, mas ajuda a identificar consultas problemáticas durante um pico):

SELECT query, calls, rows AS total_rows,
  round(total_exec_time::numeric, 2) AS total_exec_time_ms
FROM pg_stat_statements
WHERE calls > 0
ORDER BY total_exec_time DESC
LIMIT 10;

Interpretar os resultados

Classifique os achados pelo impacto estimado de saída:

• Alta contagem de linhas + linhas largas = maior saída. Uma consulta retornando 1.000 linhas onde cada linha inclui uma coluna JSONB de 50KB transfere ~50MB por chamada.
• Frequência extrema de chamadas em até mesmo consultas pequenas se acumula. Uma consulta chamada 50.000 vezes/dia retornando 10 linhas cada = 500.000 linhas/dia.
• Cruze com o esquema para identificar quais colunas são largas. Procure por colunas JSONB, TEXT, BYTEA e VARCHAR grandes.

Passo 2: Analisar base de código

Para cada consulta identificada no Passo 1, ou para cada consulta de banco de dados na base de código se não houver estatísticas disponíveis, verifique:

• Ela seleciona apenas as colunas que a resposta precisa?
• Ela retorna um número limitado de linhas (LIMIT/paginação)?
• Ela é chamada com frequência suficiente para se beneficiar do cache?
• Ela busca dados brutos que são agregados no código da aplicação?
• Ela usa um JOIN que duplica dados pais entre linhas filhas?

Passo 3: Corrigir

Aplique a correção apropriada para cada problema encontrado. Abaixo estão os anti-padrões de saída mais comuns e como corrigi-los.

Colunas não utilizadas (SELECT *)

Problema: A consulta busca todas as colunas, mas a aplicação usa apenas algumas. Colunas grandes (blobs JSONB, campos TEXT) são transferidas pela rede e descartadas.

Antes:

SELECT * FROM products;

Depois:

SELECT id, name, price, image_urls FROM products;

Paginação ausente

Problema: Um endpoint de lista retorna todas as linhas sem LIMIT. Este é um risco de saída ilimitado — cada nova linha na tabela aumenta a transferência de dados em cada solicitação. Sinalize isso independentemente do tamanho atual da tabela.

…