Lendo o planner do Postgres sem piscar

Boa parte do medo em torno de planos de execução vem de lê-los de cima para baixo, como um stack trace. O planner do Postgres não funciona assim — ele estima custo de baixo para cima, das folhas da árvore do plano até a raiz, e a primeira coisa que vale a pena fazer é achar onde a estimativa de linhas diverge do número real. É quase sempre ali que o plano dá errado.

BUFFERS é a opção que ninguém liga por padrão e todo mundo deveria. Ela mostra quanto do trabalho veio do cache e quanto veio de leitura em disco, transformando “essa query está lenta” em “essa query está fazendo 40 mil leituras sem cache” — um problema que dá pra atacar de verdade.

Três reescritas cobrem a maior parte do que eu corrijo: empurrar um filtro para mais cedo, pra o planner não varrer linhas que vai descartar; trocar um cast implícito que desativa um índice sem avisar; e reescrever uma subquery correlacionada como um join, pra o planner poder escolher uma estratégia de hash em vez de nested loops. Nada disso exige conhecimento exótico — exige ler o plano devagar o suficiente pra notar onde a estimativa mentiu.

O objetivo não é decorar cada tipo de nó. É criar o hábito de perguntar “onde a estimativa e a realidade discordaram” toda vez, e tratar a resposta como o verdadeiro relatório do bug.