Asumiendo que sus tablas de interés tienen (o pueden ser aumentadas con) una clave única, indexada y secuencial, obtendrá un valor mucho mejor simplemente emitiendo SELECT ... FROM table ... WHERE key > :last_max_key con salida a un archivo, donde last_max_key es el último valor clave de la última extracción (0 si es la primera extracción). Este enfoque incremental y desacoplado evita introduciendo latencia de activación en la ruta de datos de inserción (ya sean disparadores personalizados o Slony modificado), y dependiendo de su configuración podría escalar mejor con la cantidad de CPU, etc. (Sin embargo, si también tiene que seguir UPDATE s , y usted agregó la clave secuencial, entonces su UPDATE las declaraciones deben SET la columna clave a NULL por lo que obtiene un nuevo valor y es elegido por la siguiente extracción. No podría realizar un seguimiento de DELETE s sin disparador.) ¿Es esto lo que tenía en mente cuando mencionó Talend?
No usaría la función de registro a menos que no pueda implementar la solución anterior; lo más probable es que el registro implique bloquear la sobrecarga para asegurarse de que las líneas de registro se escriban secuencialmente y no se superpongan/sobrescriban entre sí cuando varios backends escriben en el registro (verifique la fuente de Postgres). La sobrecarga de bloqueo puede no ser catastrófica, pero puede prescindir de ella si puede usar el incremental SELECT alternativa. Además, el registro de declaraciones ahogaría cualquier mensaje útil de ADVERTENCIA o ERROR, y el análisis en sí mismo no será instantáneo .
A menos que esté dispuesto a analizar las WAL (incluido el seguimiento del estado de la transacción y esté listo para reescribir el código cada vez que actualice Postgres), tampoco usaría necesariamente las WAL, es decir, a menos que tenga el hardware adicional disponible , en cuyo caso podría enviar WAL a otra máquina para su extracción (en la segunda máquina puede usar activadores descaradamente -- o incluso el registro de declaraciones -- ya que pase lo que pase allí no afecta a INSERT /UPDATE /DELETE rendimiento en la máquina principal). Tenga en cuenta que, en cuanto al rendimiento (en la máquina principal), a menos que pueda escribir los registros en una SAN, obtendrá un impacto de rendimiento comparable (en términos de paliza de caché del sistema de archivos, principalmente) al enviar WAL a una máquina diferente a partir de la ejecución del SELECT incremental .
