Za předpokladu, že vaše zájmové tabulky mají (nebo je lze rozšířit) jedinečným, indexovaným, sekvenčním klíčem, získáte mnohem lepší hodnotu z pouhého vydání klíče SELECT ... FROM table ... WHERE key > :last_max_key s výstupem do souboru, kde last_max_key je poslední klíčová hodnota z poslední extrakce (0 v případě první extrakce.) Tento přírůstkový, oddělený přístup zamezí zavádíme latenci spouštění v datové cestě vkládání (ať už jde o vlastní spouštěče nebo upravené Slony) a v závislosti na vašem nastavení by se mohl lépe škálovat s počtem CPU atd. (Pokud však musíte také sledovat UPDATE sa , a sekvenční klíč jste přidali vy, pak váš UPDATE příkazy by měly SET sloupec klíče na NULL takže získá novou hodnotu a bude vybrána další extrakcí. Nebylo možné sledovat DELETE sa bez spouště.) Měl jsi na mysli tohle, když jsi zmínil Talend?
Nepoužil bych možnost protokolování, pokud nemůžete implementovat výše uvedené řešení; protokolování s největší pravděpodobností zahrnuje zamykání režie aby se zajistilo, že řádky protokolu budou zapsány postupně a nebudou se navzájem překrývat/přepisovat, když do protokolu zapisuje více backendů (zkontrolujte zdroj Postgres.) Režie zamykání nemusí být katastrofální, ale můžete se bez něj obejít, pokud můžete použít inkrementální SELECT alternativní. Navíc by se protokolování výpisů utopilo jakékoli užitečné zprávy WARNING nebo ERROR a samotná analýza neproběhne okamžitě .
Pokud nejste ochotni analyzovat WAL (včetně sledování stavu transakcí a připravenosti přepsat kód pokaždé, když upgradujete Postgres), nemusel bych nutně používat ani WAL – tedy pokud nemáte k dispozici další hardware silný> , v takovém případě můžete odeslat WAL na jiný počítač k extrakci (na druhém stroji můžete bezostyšně používat spouštěče -- nebo dokonce protokolování příkazů -- protože cokoliv se tam stane, neovlivní INSERT /UPDATE /DELETE výkon na primárním počítači.) Všimněte si, že pokud jde o výkon (na primárním počítači), pokud nemůžete zapisovat protokoly do SAN, získáte srovnatelný výkon (většinou ve smyslu ničení mezipaměti souborového systému) při dodání WAL na jiný počítač jako při spuštění inkrementálního SELECT .