Forudsat at dine interessetabeller har (eller kan udvides med) en unik, indekseret, sekventiel nøgle, så vil du få meget meget bedre værdi ud af blot at udstede SELECT ... FROM table ... WHERE key> :last_max_key med output til en fil, hvor last_max_key er den sidste nøgleværdi fra den sidste ekstraktion (0 hvis første ekstraktion.) Denne inkrementelle, afkoblede tilgang undgår introducerer trigger latency i indsættelsesdatastien (det være sig brugerdefinerede triggere eller modificeret Slony), og afhængigt af din opsætning kunne den skalere bedre med antallet af CPU'er osv. (Men hvis du også skal spore OPDATERING s , og den sekventielle nøgle blev tilføjet af dig, derefter din OPDATERING sætninger skal SET nøglekolonnen til NULL så det får en ny værdi og bliver plukket ved næste ekstraktion. Du ville ikke være i stand til at spore DELETE s uden en trigger.) Er det det, du havde i tankerne, da du nævnte Talend?
Jeg ville ikke bruge logningsfaciliteten, medmindre du ikke kan implementere løsningen ovenfor; logning involverer højst sandsynligt låsning af overhead for at sikre, at loglinjer skrives sekventielt og ikke overlapper/overskriver hinanden, når flere backends skriver til loggen (tjek Postgres-kilden.) Låseoverhead er muligvis ikke katastrofalt, men du kan undvære det, hvis du kan bruge inkrementelle VÆLG alternativ. Desuden ville erklæringslogning drukne eventuelle nyttige ADVARSEL- eller FEJL-meddelelser, og selve parsingen vil ikke være øjeblikkelig .
Medmindre du er villig til at parse WAL'er (inklusive transaktionstilstandssporing og være klar til at omskrive koden hver gang du opgraderer Postgres) ville jeg heller ikke nødvendigvis bruge WAL'erne -- det vil sige, medmindre du har den ekstra hardware tilgængelig stærk> , i hvilket tilfælde du kan sende WAL'er til en anden maskine til udvinding (på den anden maskine kan du bruge triggere skamløst -- eller endda sætningslogning -- da hvad der end sker der ikke påvirker INSERT /OPDATERING /SLET ydelse på den primære maskine.) Bemærk, at ydelsesmæssigt (på den primære maskine), medmindre du kan skrive logfilerne til et SAN, vil du få et sammenligneligt præstationshit (for det meste med hensyn til at tæske filsystemcache) fra forsendelse af WAL'er til en anden maskine fra at køre den inkrementelle SELECT .