Mejores Prácticas de Particionamiento
Planifica el número de particiones; evita particiones diarias para siempre. Particiona para patrones de acceso amigables con la poda (prune-friendly) y retención operable, no porque la tabla "se sienta grande".
Cómo Usar Esta Lista
- Completa antes de particionar una tabla con más de 50 millones de filas.
- Revisa cuando el tiempo de planificación o el número de particiones crucen los umbrales de alerta.
- Cada tabla particionada en producción necesita un propietario para el cron de automatización de particiones.
- Almacena la prueba de poda (
EXPLAIN) en el runbook de la tabla.
A - Selección de Estrategia
- Particiona en predicados que las consultas usan siempre. Tiempo (
occurred_at), inquilino (tenant_id), o región - no IDs arbitrarios. - Prefiere particiones de rango mensuales o semanales para series temporales. Diarias solo con volumen extremo, automatización y monitorización.
- Limita el número de particiones activas a unos pocos cientos. Miles de hijos degradan la planificación y las consultas de catálogo.
- Documenta la política de retención por tabla particionada. Horario de desvinculación (detach), requisito de copia de seguridad, excepciones de retención legal.
- Demuestra la necesidad con métricas de tamaño y vacuum. El particionamiento no es un sustituto de índices faltantes.
B - DDL y Claves
- Incluye la clave de partición en PRIMARY KEY y UNIQUE. Planifica la unicidad global mediante tablas secundarias si es necesario.
- Automatiza la creación de particiones futuras (N+2 adelante). Nunca dependas de DDL manual a medianoche.
- Indexa las columnas principales de la clave de partición que coincidan con los filtros de consulta.
(tenant_id, occurred_at DESC)para consultas de inquilino-tiempo. - Evita la partición por defecto en estado estable. Úsala solo durante la migración; alerta sobre el crecimiento de la partición por defecto.
- Prueba ATTACH/DETACH en clones de staging con recuentos de filas de producción. Valida la duración del bloqueo antes de producción.
C - Consultas y Aplicación
- Requiere filtro de clave de partición en consultas de ruta activa (hot-path). La capa de repositorio rechaza escaneos de tiempo sin límites en OLTP.
- Almacena timestamps como
timestamptzUTC. Los límites de poda deben coincidir con la representación almacenada. - Prohíbe funciones en la clave de partición en el WHERE. No usar
date_trunccomo envoltorio en plantillas SQL de producción. - Ejecuta
EXPLAINen CI para consultas canónicas. Asegura que aparezcan nombres de particiones hijo esperados. - Educa a las herramientas de BI para que pasen ventanas de tiempo. Los informes completos ad-hoc pertenecen a réplicas o al almacén de datos (warehouse).
D - Operaciones
- Usa DETACH + DROP para retención, no DELETE masivo. Protege autovacuum y el retraso de replicación.
- Descarga las particiones desvinculadas antes de DROP cuando el cumplimiento lo requiera. Verifica la restauración de copias de seguridad trimestralmente.
- Monitoriza el recuento de particiones, el tamaño de la partición por defecto y el tiempo de planificación p95. Alerta antes de que los usuarios noten latencia.
- Ejecuta ANALYZE en el padre después de una carga masiva a un nuevo hijo. Las estadísticas obsoletas causan planes incorrectos en todas las particiones.
- Documenta el procedimiento de re-adjuntar/restaurar. Operaciones puede recuperar un mes sin una restauración completa del clúster.
Preguntas Frecuentes
¿Cuál es una buena primera tabla para particionar?
Registros de eventos o auditoría de solo adición con consultas acotadas por tiempo y retención de 90 días: clave clara, poda clara, desvinculación clara.
¿Particiones mensuales vs. semanales?
Semanales cuando las particiones de un solo mes exceden un tamaño cómodo (aproximadamente 50-100 GB+) o la retención es semanal. De lo contrario, las mensuales reducen la sobrecarga del catálogo.
¿Deben los índices ser locales o globales?
PostgreSQL utiliza índices físicos por hijo creados a través de DDL del padre. No existe un índice "global" separado entre particiones sin la clave de partición.
¿Cómo nombro las particiones?
events_2026_03 para marzo de 2026: ordenable, fácil de buscar (grep-friendly) en scripts de operaciones.
¿Puede el particionamiento reemplazar el sharding?
No. El particionamiento es de un solo nodo (o un solo primario). La escala de escritura multinodo requiere Citus, sharding de aplicaciones o bases de datos divididas.
¿Qué métricas activan la revisión del particionamiento?
Recuento de hijos en pg_class, tiempo de planificación de EXPLAIN, duración de autovacuum en el padre, errores de inserción en el límite del mes.
¿Es el particionamiento hash bueno para series temporales?
Raramente. Hash distribuye las escrituras pero los informes de rango de tiempo escanean todas las particiones. Prefiere rango con filtro de tiempo.
¿Cómo interactúa el particionamiento con PgBouncer?
Transparente: el pooling no afecta la poda. Asegúrate de que las sentencias preparadas aún pasen parámetros amigables con el particionamiento.
¿Deben las tablas `foreign` (externas) contener archivos de archivo?
Patrón opcional: desvincular, volcar a parquet, consultar a través de postgres_fdw o motor externo para auditorías raras.
¿Cuándo es prematuro el particionamiento?
Tablas de dimensión pequeñas, filas actualizadas frecuentemente dispersas en el tiempo, o consultas sin filtros de clave de partición.
Relacionado
- Conceptos Básicos de Particionamiento - ejemplos introductorios
- Poda de Particiones - prueba la reducción del escaneo
- Retención y Desvinculación - operaciones del ciclo de vida
- Errores Comunes de Particionamiento - errores a evitar
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.