対象のテーブルが一意のインデックス付きシーケンシャルキーを持っている（または拡張できる）と仮定すると、 SELECT ... FROM table ... WHERE key>を発行するだけで、はるかに優れた値が得られます。 last_max_key last_max_keyがファイルに出力されます は最後の抽出からの最後のキー値です（最初の抽出の場合は0）。このインクリメンタルな分離アプローチは回避します 挿入データパスに遅延をトリガーする （カスタムトリガーであれ、変更されたSlonyであれ）、セットアップによっては、CPUの数などに応じて拡張性が向上する可能性があります（ただし、 UPDATEを追跡する必要がある場合 s 、シーケンシャルキーが追加された後、 UPDATE ステートメントはSETである必要があります NULLへのキー列 したがって、新しい値を取得し、次の抽出で選択されます。 DELETEを追跡することはできません s トリガーなしで。）これは、Talendについて言及したときに念頭に置いていたものですか？
上記のソリューションを実装できない場合を除いて、ログ機能は使用しません;ロギングには、オーバーヘッドのロックが含まれる可能性があります ログ行が順番に書き込まれ、複数のバックエンドがログに書き込むときに互いにオーバーラップ/上書きされないようにするため（Postgresソースを確認してください）。ロックのオーバーヘッドは壊滅的ではないかもしれませんが、インクリメンタル<を使用できる場合はそれなしで行うことができますcode> SELECT 別。さらに、ステートメントのログ記録は溺れます 有用な警告またはエラーメッセージ、および解析自体は瞬時には行われません 。
WALを解析する意思がない限り（トランザクション状態の追跡を含み、Postgresをアップグレードするたびにコードを書き直す準備ができている場合）、必ずしもWALを使用する必要はありません。つまり、追加のハードウェアを利用できる場合を除きます 、その場合、抽出のためにWALを別のマシンに出荷することができます。 （2番目のマシンでは、恥知らずにトリガーを使用できます -またはステートメントロギング-そこで何が起こってもINSERTには影響しないため / UPDATE / DELETE プライマリマシンでのパフォーマンス。）パフォーマンスに関して（プライマリマシンで）、ログをSANに書き込めない限り、WALの出荷によって（ファイルシステムキャッシュのスラッシングに関して）同等のパフォーマンスヒットが得られることに注意してください。インクリメンタルSELECTの実行とは別のマシンに 。