Optimizando PostgreSQL para datos transitorios

Tengo varias tablas con 100-300 columnas de tipos enteros cada una, que contienen datos altamente volátiles. Los conjuntos de datos están codificados por una o dos claves principales, y cuando se produce la actualización, se elimina todo el conjunto de datos y se insertan datos nuevos en una transacción. El tamaño del conjunto de datos suele ser de unos cientos de filas, pero puede ser de varios miles de filas en casos extremos. La actualización se produce una vez por segundo, y las actualizaciones de conjuntos de datos para diferentes claves generalmente están desarticuladas, por lo que no es posible descartar y volver a crear la tabla.

¿Cómo ajusto Postgres para manejar dicha carga? Puedo usar la última y mejor versión si eso hace alguna diferencia.

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, BEGINuna nueva transacción, TRUNCATEla tabla, COPYlos nuevos datos en él y COMMIT. PostgreSQL tiene una optimización en COPYing en una tabla que ha sido TRUNCATEd 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 initdbantes 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 unloggedtablas, 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 .