Melhores Práticas de Particionamento
Planeje a contagem de partições; evite partições diárias para sempre. Particione para padrões de acesso amigáveis à poda (prune-friendly) e retenção operável, não porque a tabela "parece grande".
Como Usar Esta Lista
- Complete antes de particionar uma tabela com mais de 50 milhões de linhas.
- Revise quando o tempo de planejamento ou a contagem de partições ultrapassar os limites de alerta.
- Toda tabela particionada em produção precisa de um proprietário para o cron de automação de partições.
- Armazene a prova de poda (
EXPLAIN) no runbook da tabela.
A - Seleção de Estratégia
- Particione em predicados que as consultas sempre usam. Tempo (
occurred_at), inquilino (tenant_id) ou região - não IDs arbitrários. - Prefira partições de intervalo mensais ou semanais para séries temporais. Diárias apenas em volume extremo com automação e monitoramento.
- Limite a contagem de partições ativas abaixo de algumas centenas. Milhares de filhos degradam o planejamento e as consultas de catálogo.
- Documente a política de retenção por tabela particionada. Agendamento de desanexação, requisito de backup, exceções de retenção legal.
- Comprove a necessidade com métricas de tamanho e vacuum. O particionamento não é um substituto para índices ausentes.
B - DDL e Chaves
- Inclua a chave de partição em PRIMARY KEY e UNIQUE. Planeje a exclusividade global por meio de tabelas auxiliares, se necessário.
- Automatize a criação de partições futuras (N+2 à frente). Nunca confie em DDL manual à meia-noite.
- Indexe as colunas principais da chave de partição correspondentes aos filtros de consulta.
(tenant_id, occurred_at DESC)para consultas de inquilino-tempo. - Evite a partição padrão em estado estável. Use apenas durante a migração; alerte sobre o crescimento padrão.
- Teste ATTACH/DETACH em clones de staging com contagens de linhas de produção. Valide a duração do bloqueio antes da produção.
C - Consulta e Aplicação
- Exija filtro de chave de partição em consultas de caminho crítico (hot-path). A camada de repositório rejeita varreduras de tempo ilimitadas em OLTP.
- Armazene timestamps como
timestamptzUTC. Os limites de poda devem corresponder à representação armazenada. - Proíba funções na chave de partição em WHERE. Sem wrapper
date_truncem templates SQL de produção. - Execute
EXPLAINem CI para consultas canônicas. Afirme que os nomes esperados das partições filhas aparecem. - Eduque ferramentas de BI para passar janelas de tempo. Relatórios ad-hoc de tabela completa pertencem à réplica ou ao data warehouse.
D - Operações
- Use DETACH + DROP para retenção, não DELETE em massa. Proteja o autovacuum e o atraso de replicação.
- Descarregue partições desanexadas antes de DROP quando a conformidade exigir. Verifique a restauração do backup trimestralmente.
- Monitore a contagem de partições, o tamanho da partição padrão e o tempo de planejamento p95. Alerte antes que os usuários notem latência.
- Execute ANALYZE no pai após carga em massa para um novo filho. Estatísticas desatualizadas causam planos ruins entre partições.
- Documente o procedimento de reanexação/restauração. A equipe de operações pode recuperar um mês sem a restauração completa do cluster.
FAQs
Qual é uma boa primeira tabela para particionar?
Logs de eventos ou auditoria somente anexáveis com consultas limitadas por tempo e retenção de 90 dias - chave clara, poda clara, desanexação clara.
Partições mensais vs. semanais?
Semanais quando partições de um mês excedem o tamanho confortável (aproximadamente 50-100 GB+) ou a retenção é semanal. Caso contrário, mensal reduz a sobrecarga do catálogo.
Os índices devem ser locais ou globais?
O PostgreSQL usa índices físicos por filho criados via DDL pai. Não há um índice "global" separado entre partições sem a chave de partição.
Como nomeio as partições?
events_2026_03 para março de 2026 - classificável, fácil de buscar em scripts de operações.
O particionamento pode substituir o sharding?
Não. O particionamento é de nó único (ou primário único). A escala de escrita multi-nó requer Citus, sharding de aplicação ou bancos de dados divididos.
Quais métricas disparam a revisão de partições?
Contagem de filhos em pg_class, tempo de planejamento de EXPLAIN, duração do autovacuum no pai, erros de inserção no limite do mês.
O particionamento hash é bom para séries temporais?
Raramente. Hash distribui as escritas, mas relatórios de intervalo de tempo escaneiam todas as partições. Prefira intervalo com filtro de tempo.
Como o particionamento interage com o PgBouncer?
Transparente - o pooling não afeta a poda. Certifique-se de que as instruções preparadas ainda passem parâmetros amigáveis à partição.
Tabelas estrangeiras devem conter arquivos arquivados?
Padrão opcional: desanexar, descarregar para parquet, consultar via postgres_fdw ou motor externo para auditorias raras.
Quando o particionamento é prematuro?
Tabelas de dimensão pequenas, linhas pesadamente atualizadas espalhadas pelo tempo, ou consultas sem filtros de chave de partição.
Relacionados
- Noções Básicas de Particionamento - exemplos introdutórios
- Poda de Partição - prova de redução de varredura
- Retenção e Desanexação - operações de ciclo de vida
- Armadilhas de Particionamento - erros a evitar
Versões de Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.