PostgreSQL • Partições

As partições dividem uma tabela grande em partes menores gerenciadas pelo PostgreSQL. Com a particionamento declarativo (RANGE, LIST e HASH), você melhora manutenção, possivelmente performance (com partition pruning) e facilita arquivamento.

Quando considerar particionar

• Tabelas muito grandes (dezenas/centenas de milhões de linhas).
• Consultas quase sempre filtram por uma chave natural (ex.: data, região, empresa_id).
• Necessidade de arquivar / descartar períodos antigos com impacto mínimo.
• Janelas de manutenção longas em tabelas monolíticas.

Dica: Se suas consultas não filtram pela coluna de partição, o ganho pode ser limitado.

Tipos de partição (PostgreSQL)

RANGE

• Divide por intervalos (ex.: data por mês/ano).
• Ex.: 2025-01, 2025-02, …, e uma partição DEFAULT para “o resto”.
• Excelente para relatórios por período e arquivamento mensal.

LIST

• Divide por valores discretos (ex.: país, UF, tenant_id pequeno).
• Bom quando os grupos são bem definidos e em número controlado.

HASH

• Espalha linhas entre N partições com base em hash da coluna.
• Útil para balancear escrita quando não há uma chave temporal natural.

Abrir “Gerenciar Partições”

1. Conecte-se à sua conexão PostgreSQL e selecione o banco.
2. Na árvore, escolha a tabela alvo.
3. No menu de ações, toque em Partições.

O painel mostra o tipo de particionamento, a coluna-chave e a lista de partições já criadas.

Operações comuns

Criar partições

1. Defina o tipo (RANGE/LIST/HASH) e a coluna de partição.
2. Informe o plano inicial (ex.: partições mensais de 12 meses + uma DEFAULT).
3. Confirme em Criar. O app gera a tabela particionada e as partições-filhas.

Adicionar partição

• Use quando chega um novo período/valor (ex.: próximo mês ou novo país).
• Informe o intervalo/valor e confirme para ATTACH PARTITION.

Remover / arquivar partição

• Para RANGE, remova meses/anos antigos após backup/ETL.
• Você pode DETACH PARTITION para transformá-la numa tabela independente e arquivá-la.

Índices e constraints

• Crie índices na tabela-particionada (o Postgres replica nos filhos).
• Importante: constraints UNIQUE/PK na tabela-particionada devem incluir a coluna de partição para garantir unicidade global.

Boas práticas

• Escolha a coluna de partição mais usada nos filtros (normalmente data).
• Mantenha uma partição DEFAULT para capturar registros fora dos intervalos esperados.
• Automatize a criação de novas partições (ex.: cron para o próximo mês).
• Evite milhares de partições; prefira um número equilibrado (dezenas/centenas conforme o caso).
• Combine com índices adequados nas colunas mais filtradas dentro de cada partição.

Limitações e observações

• Consultas sem filtro na coluna de partição podem varrer muitas partições.
• Algumas operações DDL reconstroem índices/constraints nas partições — planeje janela.
• Triggers e FKs funcionam, mas valide impacto e cardinalidade em cargas altas.

Erros comuns (e soluções)

“Intervalo/valor já coberto por outra partição”

• Revise seus limites de RANGE/LIST; não pode haver sobreposição.

“UNIQUE/PK não pode ser criado”

• Inclua a coluna de partição na PK/UNIQUE da tabela-particionada.

“Consulta continua lenta mesmo com partição”

• Garanta que o WHERE use a coluna de partição (permite partition pruning).
• Crie índices apropriados nos filhos (ou no pai, para replicar).

“Partições demais”

• Consolide períodos antigos (menos partições) ou arquive via DETACH.

Ferramentas relacionadas

• Estrutura geral: PostgreSQL • Estrutura da Tabela.
• Índices: PostgreSQL • Índices.
• Consulta rápida: PostgreSQL • Executar SELECT.
• Manutenção e otimização: PostgreSQL • Manutenção.

Próximo: PostgreSQL • Manutenção • Voltar: PostgreSQL • Funções