Supponendo che le tue tabelle di interesse abbiano (o possano essere aumentate con) una chiave sequenziale univoca, indicizzata, otterrai un valore molto migliore semplicemente emettendo SELECT ... FROM table ... WHERE key > :last_max_key con output in un file, dove last_max_key è l'ultimo valore chiave dell'ultima estrazione (0 se la prima estrazione). Questo approccio incrementale e disaccoppiato evita introducendo latenza del trigger nel percorso dati di inserimento (che si tratti di trigger personalizzati o Slony modificato) e, a seconda della tua configurazione, potrebbe scalare meglio con il numero di CPU ecc. (Tuttavia, se devi anche tracciare UPDATE s , e la chiave sequenziale è stata aggiunta da te, quindi il tuo UPDATE le istruzioni dovrebbero SET la colonna chiave su NULL quindi ottiene un nuovo valore e viene prelevato dall'estrazione successiva. Non saresti in grado di monitorare DELETE s senza un trigger.) Era questo che avevi in mente quando hai menzionato Talend?
Non userei la funzione di registrazione a meno che tu non possa implementare la soluzione sopra; la registrazione molto probabilmente implica il blocco del sovraccarico per garantire che le righe di registro vengano scritte in sequenza e non si sovrappongano/sovrascrivano l'una con l'altra quando più backend scrivono nel registro (controlla il sorgente di Postgres.) L'overhead di blocco potrebbe non essere catastrofico, ma puoi farne a meno se puoi utilizzare l'incremento SELECT alternativa. Inoltre, la registrazione delle istruzioni verrebbe meno eventuali messaggi di AVVISO o ERRORE utili e l'analisi stessa non sarà istantanea .
A meno che tu non sia disposto ad analizzare i WAL (incluso il monitoraggio dello stato delle transazioni ed essere pronto a riscrivere il codice ogni volta che esegui l'upgrade di Postgres), non userei necessariamente nemmeno i WAL, cioè, a meno che tu non disponga dell'hardware extra , nel qual caso potresti spedire i WAL a un'altra macchina per l'estrazione (sulla seconda macchina puoi usare i trigger senza vergogna -- o anche la registrazione delle istruzioni -- poiché qualunque cosa accada non ha effetto su INSERT /UPDATE /DELETE prestazioni sulla macchina principale.) Nota che dal punto di vista delle prestazioni (sulla macchina principale), a meno che tu non riesca a scrivere i registri su una SAN, otterresti un aumento delle prestazioni comparabile (in termini di thrashing della cache del filesystem, principalmente) dalla spedizione di WAL su una macchina diversa dall'esecuzione di SELECT incrementale .
