Ако приемем, че вашите интересни таблици имат (или могат да бъдат разширени с) уникален, индексиран, последователен ключ, тогава ще получите много по-добра стойност от простото издаване на SELECT ... FROM table ... WHERE key > :last_max_key с изход към файл, където last_max_key е последната ключова стойност от последното извличане (0, ако е първото извличане.) Този инкрементален, отделен подход избягва въвеждане на закъснение на задействане в пътя на данните за вмъкване (било то персонализирани тригери или модифициран Slony) и в зависимост от вашата настройка може да се мащабира по-добре с брой процесори и т.н. (Въпреки това, ако трябва също да проследите UPDATE са , и последователният ключ е добавен от вас, след това вашият UPDATE изразите трябва да SET ключовата колона на NULL така че получава нова стойност и се избира от следващото извличане. Вие няма да можете да проследите DELETE са без задействане.) Това ли имахте предвид, когато споменахте Talend?
Аз не бих използвал инструмента за регистриране, освен ако не можете да приложите горното решение; регистрирането най-вероятно включва режим на заключване за да се гарантира, че редовете на регистрационния файл се записват последователно и не се припокриват/презаписват един друг, когато няколко бекенда пишат в журнала (проверете източника на Postgres.) Заключващите допълнителни разходи може да не са катастрофални, но можете да го направите без него, ако можете да използвате инкременталния SELECT алтернатива. Нещо повече, записването на извлечения би заглушило всички полезни съобщения ПРЕДУПРЕЖДЕНИЕ или ГРЕШКА и самото анализиране няма да бъде мигновено .
Освен ако не желаете да анализирате WAL (включително проследяване на състоянието на транзакциите и да сте готови да пренаписвате кода всеки път, когато надграждате Postgres), не бих използвал непременно и WAL – тоест, освен ако имате наличен допълнителен хардуер , в който случай можете да изпратите WAL на друга машина за извличане (на втората машина можете да безсрамно използвате тригери -- или дори регистриране на оператори -- тъй като каквото и да се случи там, не засяга INSERT /UPDATE /DELETE производителност на основната машина.) Обърнете внимание, че по отношение на производителността (на основната машина), освен ако не можете да запишете регистрационните файлове в SAN, ще получите сравнимо постижение на производителността (най-вече по отношение на разбиването на кеша на файловата система) от изпращането на WAL към друга машина от стартиране на инкременталния SELECT .
