Om du antar att dina intressetabeller har (eller kan utökas med) en unik, indexerad, sekventiell nyckel, kommer du att få mycket mycket bättre värde av att helt enkelt utfärda SELECT ... FROM table ... WHERE key > :last_max_key med utdata till en fil, där last_max_key är det sista nyckelvärdet från den senaste extraheringen (0 om första extraheringen.) Denna inkrementella, frikopplade metod undviker introducerar trigger latens i infogningsdatasökvägen (oavsett om det är anpassade triggers eller modifierad Slony), och beroende på din inställning kan det skalas bättre med antal CPU:er etc. (Men om du också måste spåra UPDATE s , och den sekventiella nyckeln lades till av dig, sedan din UPDATE satser bör SET nyckelkolumnen till NULL så det får ett nytt värde och plockas av nästa extraktion. Du skulle inte kunna spåra DELETE s utan en trigger.) Var det detta du hade i åtanke när du nämnde Talend?
Jag skulle inte använda loggningsfunktionen om du inte kan implementera lösningen ovan; loggning innebär sannolikt låsning av overhead för att säkerställa att loggrader skrivs sekventiellt och inte överlappar/skriver över varandra när flera backends skriver till loggen (kontrollera Postgres-källan.) Låsningsoverheaden kanske inte är katastrofal, men du kan klara dig utan den om du kan använda den inkrementella SELECT alternativ. Dessutom skulle påståendeloggning drunkna några användbara VARNINGS- eller FELmeddelanden, och parsningen i sig kommer inte att ske omedelbar .
Om du inte är villig att analysera WALs (inklusive spårning av transaktionstillstånd och att vara redo att skriva om koden varje gång du uppgraderar Postgres) skulle jag inte nödvändigtvis använda WALs heller -- det vill säga om du inte har den extra hårdvaran tillgänglig stark> , i så fall kan du sända WALs till en annan maskin för utvinning (på den andra maskinen kan du använda triggers skamlöst -- eller till och med satsloggning -- eftersom vad som än händer där inte påverkar INSERT /UPDATE /DELETE prestanda på den primära maskinen.) Observera att prestandamässigt (på den primära maskinen), såvida du inte kan skriva loggarna till ett SAN, skulle du få en jämförbar prestandaträff (i termer av att filsystems cache förstörs) från att skicka WAL:er till en annan dator från att köra den inkrementella SELECT .