Dependiendo de cuántos conjuntos de datos diferentes hay, una opción sería dividir las tablas por conjunto de datos.
Cuando se actualiza un conjunto de datos, BEGIN
una nueva transacción, TRUNCATE
la tabla, COPY
los nuevos datos en él y COMMIT
. PostgreSQL tiene una optimización en COPY
ing en una tabla que ha sido TRUNCATE
d en la misma transacción hace mucho menos de E / S si está utilizando wal_level = minimal
(por defecto).
Si no puede particionar y truncar (por ejemplo, si se trata de decenas o cientos de miles de conjuntos de datos, donde habría demasiadas tablas), en su lugar, querrá aumentar el vacío automático para ejecutar todo lo que pueda , asegúrese de tener buenos índices en todo lo que elimine en función de, y esté preparado para un rendimiento algo normal.
Si no necesita protección contra fallas, no le importa que sus tablas estén vacías después de una falla del sistema, también puede crear sus tablas como UNLOGGED
, lo que le ahorrará una gran cantidad de costos de E / S.
Si no le importa tener que restaurar toda la configuración desde una copia de seguridad después de un bloqueo del sistema, puede ir un paso más allá y también configurar fsync=off
, lo que básicamente le dice a PostgreSQL "no se preocupe por la seguridad del bloqueo, tengo buenas copias de seguridad y no No me importa si mis datos son irrecuperables de forma permanente y total después de un bloqueo, y estoy feliz de poder recuperarlos initdb
antes de poder usar mi base de datos nuevamente ".
Escribí algo más sobre esto en un hilo similar en Stack Overflow sobre la optimización de PostgreSQL para pruebas rápidas ; que menciona el ajuste del sistema operativo host, separando WAL en un disco diferente si no está utilizando unlogged
tablas, ajustes de puntero de verificación, etc.
También hay información en los documentos de Pg para la carga rápida de datos y configuraciones no duraderas .