私にはリストがあり、そのリストは増え続けています。リストのサイズに応じてバッチを追加しています。 do executeBatchの制限を指定されたサイズにすることを忘れました。
プログラムは何時間も働いています。とりあえず、停止、修正、再開したくありません。
私の質問、追加するバッチのサイズを決定するものは何ですか?一度にexecuteBatch()
を実行するバッチの最大容量はいくつですか? executeBatch()
なしで何回addBatch
を使用できますか?
PgJDBCには、バッチに関していくつかの制限があります。
すべてのリクエスト値とすべての結果は、メモリに蓄積する必要があります。これには、大きなblob/clobの結果が含まれます。したがって、空きメモリがバッチサイズの主な制限要因です。
PgJDBC 9.4(まだリリースされていない)まで) 、 生成されたキーを返すバッチは、常にすべてのエントリに対してラウンドトリップを実行します なので、個々のステートメントの実行と同じです。
9.4でも、生成されたキーを返すバッチは、生成された値のサイズが制限されている場合にのみメリットがあります。 リクエストされた結果の単一のtext
、bytea
、または制約なしvarchar
フィールドは、ドライバーに実行ごとにラウンドトリップを実行させる 。
バッチ処理の利点は、ネットワークの往復回数が減ることです。そのため、DBがアプリサーバーに対してローカルである場合は、あまり意味がありません。ネットワーク待機にかかる合計時間は急速に減少するため、バッチサイズを大きくすると収益が減少します。そのため、バッチをできるだけ大きくしようとすることにストレスがかかることはあまりありません。
データをバルクロードする場合は、COPY
インターフェースから取得したPgJDBCのCopyManager
を介して、代わりにPgConnection
APIを使用することを真剣に検討してください。これにより、CSVのようなデータをサーバーにストリーミングして、クライアント/サーバーのラウンドトリップがほとんどなく、迅速な一括読み込みが可能になります。残念ながら、それは著しく過少に文書化されています-それはメインのPgJDBCドキュメントにはまったく表示されません APIドキュメントでのみ 。
JDBC実装によっては、パラメーターマーカーの最大数がある場合があります。
たとえば、PostgreSQLドライバーはパラメーターの数を表します 2バイト整数として 、Javaは最大32768です)。
私の知る限り、メモリの問題以外に制限はありません。あなたの質問に関して:ステートメントはバッチの実行時にのみDBに送信されるため、バッチを実行するまで、JavaHeapSpaceが取得されるか、バッチがDBに送信されるまで、メモリは増加し続けます。