Если предположить, что ваши интересующие таблицы имеют (или могут быть дополнены) уникальный, индексированный, последовательный ключ, тогда вы получите намного лучшее значение от простой выдачи SELECT ... FROM table ... WHERE key > :last_max_key с выводом в файл, где last_max_key является последним значением ключа из последнего извлечения (0 при первом извлечении). Этот инкрементный, отсоединенный подход позволяет избежать введения задержки триггера в пути ввода данных (будь то пользовательские триггеры или модифицированный Slony) и, в зависимости от вашей настройки, может масштабироваться лучше с количеством процессоров и т. д. (Однако, если вам также нужно отслеживать UPDATE s , и вы добавили последовательный ключ, тогда ваши операторы UPDATE должен SET ключевой столбец для NULL, чтобы он получал новое значение и выбирался при следующем извлечении. вы не сможете отслеживать DELETE s без триггера.) Вы имели в виду, когда упомянули Talend?
Я бы не использовал средства ведения журнала, если вы не можете реализовать решение выше ; ведение журнала, скорее всего, включает накладные расходы на блокировку , чтобы гарантировать, что строки журнала записываются последовательно и не перекрываются / не перезаписываются друг друга при записи нескольких бэкэндов в журнал (проверьте источник Postgres.) Затраты на блокировку могут быть не катастрофическими, но Вы можете обойтись без него, если вы можете использовать инкрементную альтернативу SELECT. Более того, запись в журнал оператора заглушит любых полезных сообщений WARNING или ERROR, а сам синтаксический анализ не будет мгновенным .
Если вы не готовы анализировать WAL (включая отслеживание состояния транзакции и готовность переписывать код при каждом обновлении Postgres), я также не обязательно буду использовать WAL - то есть, если у вас нет дополнительного оборудования доступно , в этом случае вы можете пересылать WAL на другую машину для извлечения (на второй машине вы можете использовать триггеры бесстыдно - или даже запись операторов - так как бы ни случилось это не влияет на производительность INSERT / UPDATE / DELETE на основном компьютере.) Обратите внимание, что с точки зрения производительности (на основном компьютере), если вы не можете записывать журналы в SAN, вы получите сопоставимый снижение производительности (с точки зрения, главным образом, перебора кеша файловой системы) от доставки WAL на другой компьютер, а также от запуска инкрементного SELECT.