sharedbuffers: conhecimento que não se perde no disco

No PostgreSQL, shared_buffers é o parâmetro que define o tamanho do buffer pool — a área de memória onde as páginas de dados ficam aquecidas para que as queries não precisem buscar no disco a cada acesso.

Quando uma página está no buffer, ela está disponível para qualquer processo do banco imediatamente. Esse é o ponto: memória compartilhada que acelera tudo.

O nome deste blog vem daí, mas a metáfora vai um pouco além do parâmetro.

O que é o sharedbuffers

sharedbuffers é um blog sobre PostgreSQL. Não sobre PostgreSQL em geral — sobre o PostgreSQL que você roda em produção, que você precisa afinar quando a latência sobe às três da manhã, que você precisa entender fundo quando um cliente pergunta por que a query que funcionava ontem não funciona mais hoje.

O nome é uma dupla referência: ao parâmetro shared_buffers e à ideia de conhecimento compartilhado. Um buffer de experiências que não precisa ser recarregado do zero toda vez.

Para quem é este blog

Para quem trabalha com PostgreSQL e quer ir além do SELECT * FROM. Para DBAs que já sabem o que é um índice mas querem entender quando não criar um. Para desenvolvedores que perceberam que a query está lenta e precisam saber por onde começar. Para sysadmins que precisam configurar um servidor com critério, não com chute.

Não vamos cobrir o básico por princípio. O ponto de partida aqui é que você já tem o PostgreSQL rodando e quer entender o que acontece por baixo.

O que você vai encontrar aqui

Tuning de memória e configuração de parâmetros. Análise de planos de execução — os EXPLAIN ANALYZE que revelam o que o planejador estava pensando. Estratégias de backup, replicação e alta disponibilidade.

Tudo com exemplos reais, queries que você pode rodar no seu banco agora e comparar com o que vai encontrar aqui.

Quando fizer sentido, cada post terá versão em inglês — porque PostgreSQL não tem fronteira, e parte do que produzimos aqui merece alcance maior.

Sobre o sharedbuffers

Este blog é mantido por profissionais que trabalham com PostgreSQL em produção todo dia. A ideia foi simples desde o começo: registrar o que a gente aprende antes que suma na correria do dia a dia — e compartilhar com quem enfrenta os mesmos problemas.

Bom proveito.