{"id":2495,"date":"2026-07-29T17:36:56","date_gmt":"2026-07-29T17:36:56","guid":{"rendered":"https:\/\/www.tiagoneves.net\/blog\/?p=2495"},"modified":"2026-07-29T17:36:56","modified_gmt":"2026-07-29T17:36:56","slug":"estatisticas-no-postgresql-o-que-o-planner-enxerga","status":"publish","type":"post","link":"https:\/\/www.tiagoneves.net\/blog\/estatisticas-no-postgresql-o-que-o-planner-enxerga\/","title":{"rendered":"Estat\u00edsticas no PostgreSQL: o que o planner enxerga"},"content":{"rendered":"\n

Post 02 da s\u00e9rie “Estat\u00edsticas: SQL Server \u00d7 PostgreSQL”<\/strong> <\/p>\n\n\n\n

01 \u00b7 Estat\u00edsticas no SQL Server<\/a> <\/p>\n\n\n\n

\u2705 \u00b7 02 \u00b7 PostgreSQL (voc\u00ea est\u00e1 aqui)<\/strong> <\/p>\n\n\n\n

03 \u00b7 Comparativo (em breve)<\/p>\n\n\n\n

Ambiente usado nos exemplos: PostgreSQL 18, tabela de 5 milh\u00f5es de linhas gerada com generate_series<\/code>. Todos os comandos est\u00e3o no final para voc\u00ea reproduzir.<\/p>\n\n\n\n

O sintoma<\/mark><\/h2>\n\n\n\n

Voc\u00ea rodou ANALYZE<\/code>. O plano continua ruim.<\/p>\n\n\n\n

No SQL Server, a gente sabe o caminho: abre um DBCC SHOW_STATISTICS<\/code>, olha o histograma, o density vector, a data da \u00faltima atualiza\u00e7\u00e3o. No PostgreSQL, muita gente roda o ANALYZE<\/code>, cruza os dedos… e para por a\u00ed.<\/p>\n\n\n\n

Neste post vamos tentar entender o comportamento das estatisticas no PostgreSQL, o que exatamente o ANALYZE<\/code> coleta, onde isso fica guardado, como o planner usa cada pe\u00e7a e quem decide quando<\/strong> essa foto \u00e9 tirada (spoiler: n\u00e3o \u00e9 voc\u00ea, \u00e9 o autovacuum).<\/p>\n\n\n\n

Como no Post 01, nada aqui \u00e9 teoria de manual todos os n\u00fameros vieram de um PostgreSQL 18 real rodando na minha m\u00e1quina.<\/p>\n\n\n\n

E a escolha da vers\u00e3o n\u00e3o foi por acaso: o PostgreSQL 18 mexeu justamente em estat\u00edsticas<\/strong>, em dois pontos que mudam a rotina de quem administra base grande:<\/p>\n\n\n\n

\ud83d\udccc O que mudou no PostgreSQL 18 (e importa para este post)<\/strong><\/p>\n\n\n\n

    \n
  1. Estat\u00edsticas sobrevivem ao upgrade de vers\u00e3o maior.<\/strong> At\u00e9 o PG 17, o pg_upgrade<\/code> descartava as estat\u00edsticas do planner o cluster subia “cego” e degradava at\u00e9 o ANALYZE<\/code> geral terminar. No 18, elas s\u00e3o preservadas, e a janela de risco p\u00f3s-upgrade praticamente desaparece.
    <\/li>\n\n\n\n
  2. ANALYZE<\/code> em tabela particionada ficou recursivo por padr\u00e3o.<\/strong> Rodar na tabela-m\u00e3e agora processa tamb\u00e9m as parti\u00e7\u00f5es filhas; a nova palavra ONLY<\/code> restringe \u00e0 estrutura-m\u00e3e. Quem cuida de VLDB particionado precisa revisar os scripts de manuten\u00e7\u00e3o antes de migrar.<\/li>\n<\/ol>\n\n\n\n

    O planner cego: o que acontece sem estat\u00edstica nenhuma<\/mark><\/h2>\n\n\n\n

    Criei uma tabela vendas<\/code> com 5 milh\u00f5es de linhas e uma distribui\u00e7\u00e3o propositalmente desbalanceada o tipo de dado que a gente encontra na vida real:<\/p>\n\n\n\n