AFAIKは、 fe/beのサーバー側バッチ処理ではありません。プロトコル
、したがって、PgJDBCはそれを使用できません。 。 更新 ：まあ、私は間違っていました。 PgJDBC（9.3の時点で正確）あります 生成されたキーをフェッチする必要がない場合は、クエリのバッチをサーバーに送信します 。個々のクエリの後にサーバーと同期することなく、送信バッファに一連のクエリをキューに入れるだけです。
参照：
生成されたキーが要求された場合でも、拡張クエリプロトコル クエリテキストを毎回送信する必要がなく、パラメータだけを送信する必要があることを確認するために使用されます。
率直に言って、JDBCバッチ処理はどのような場合でも優れたソリューションではありません。アプリ開発者にとっては簡単に使用できますが、サーバーはすべてのステートメントを個別に実行する必要があるため、パフォーマンスはかなり最適ではありません。ただし、解析ではありません。 および計画 プリペアドステートメントを使用する限り、個別にそれらを使用します。
自動コミットがオンの場合、各ステートメントがコミットをトリガーするため、パフォーマンスは絶対に哀れです。自動コミットをオフにしても、ラウンドトリップ遅延をなくすことができたとしても、多くの小さなステートメントは特に高速ではありません。
多くの単純なUPDATEに対するより良いソリューション sは次のようになります：
COPYTEMPORARYへの新しいデータ またはUNLOGGEDテーブル;および-
UPDATE ... FROMを使用しますUPDATEへJOINを使用 コピーされたテーブルに対して
COPYについては、PgJDBCドキュメント
およびCOPY サーバードキュメントのドキュメント
。
アプリが個々のUPDATEをすべて送信する必要がないように、調整が可能であることがよくあります。 sまったく。