En supposant que vos tables d'intérêt ont (ou peuvent être augmentées avec) une clé séquentielle indexée unique, vous obtiendrez alors une bien meilleure valeur en émettant simplement SELECT ... FROM table ... WHERE key > :last_max_key avec sortie dans un fichier, où last_max_key est la dernière valeur de clé de la dernière extraction (0 si première extraction.) Cette approche incrémentale et découplée évite introduction de la latence de déclenchement dans le chemin de données d'insertion (qu'il s'agisse de déclencheurs personnalisés ou de Slony modifié), et selon votre configuration, cela pourrait mieux évoluer avec le nombre de processeurs, etc. (Cependant, si vous devez également suivre UPDATE s , et la clé séquentielle a été ajoutée par vous, puis votre UPDATE les instructions doivent SET la colonne clé à NULL il obtient donc une nouvelle valeur et est sélectionné par la prochaine extraction. Vous ne seriez pas en mesure de suivre DELETE s sans déclencheur.) C'est ce que vous aviez en tête lorsque vous avez mentionné Talend ?
Je n'utiliserais pas la fonction de journalisation à moins que vous ne puissiez pas implémenter la solution ci-dessus; la journalisation implique très probablement le verrouillage de la surcharge pour vous assurer que les lignes de journal sont écrites séquentiellement et ne se chevauchent pas/ne s'écrasent pas lorsque plusieurs backends écrivent dans le journal (vérifiez la source Postgres.) La surcharge de verrouillage n'est peut-être pas catastrophique, mais vous pouvez vous en passer si vous pouvez utiliser le SELECT alternative. De plus, la journalisation des instructions se noierait tout message d'AVERTISSEMENT ou d'ERREUR utile, et l'analyse elle-même ne sera pas instantanée .
À moins que vous ne souhaitiez analyser les WAL (y compris le suivi de l'état des transactions et être prêt à réécrire le code chaque fois que vous mettez à niveau Postgres), je n'utiliserais pas nécessairement les WAL non plus - c'est-à-dire, à moins que vous ayez le matériel supplémentaire disponible , auquel cas vous pourriez expédier les WAL vers une autre machine pour extraction (sur la deuxième machine, vous pouvez utiliser les déclencheurs sans vergogne -- ou même la journalisation des instructions -- puisque tout ce qui s'y passe n'affecte pas INSERT /UPDATE /DELETE performances sur la machine principale.) Notez que du point de vue des performances (sur la machine principale), à moins que vous ne puissiez écrire les journaux sur un SAN, vous obtiendrez une performance comparable (en termes de suppression du cache du système de fichiers, principalement) de l'expédition des WAL sur une autre machine à partir de l'exécution du SELECT incrémental .
