[pgsql-jp: 36263] Re: JDBCバッチ更新による性能向上
EBIHARA Yuichiro
ebihara @ iplocks.co.jp
2005年 10月 25日 (火) 23:36:31 JST
海老原です。
> ざっと見ただけですが8.0のJDBCドライバを見ると内部的には通常の
> executeQueryの実行と
> executeBatchの実行の差は「一度の呼び出しで複数の文を実行するかどうか」
という
> だけの
> ようです。つまりexecuteBatchは内部でexecuteQueryと同様の操作をループで
繰り返
> しています。
> パフォーマンスにあまり差が出ないのはそういうことではないでしょうか。
なるほど・・・。ということは、N/Wのラウンドトリップ回数すら減らないとい
うことですね。
Oracleの配列インタフェースみたいな実装を期待していましたが。
ん? セミコロンで区切って同じステートメントを複数一括実行すると、N/Wラウ
ンドトリップが減って早くなる?
PreparedStatementにINSERT文を2つ並べてやってみました。
1)No Batch
28.555s / 26.325s / 27.070s (平均27.317s)
16%高速化!
2)Batch and No ServerPrepare
27.169s / 27.033s / 27.988s (平均27.397s)
14%高速化!
3)With Batch and ServerPrepare
エラー発生
Batch entry 0 PREPARE JDBC_STATEMENT_1(integer, text, timestamptz, text,
integer, text, timestamptz, text) AS insert into batchtest values ( $1 ,
$2 , $3 , $4 );insert into batchtest values ( $5 , $6 , $7 , $8 );;
EXECUTE JDBC_STATEMENT_1( was aborted. Call getNextException() to see
the cause.
PREPAREは複文に対応していないようです。というか、PREPAREを複数並べるべき
か。
もっと並べると、もっと早くなるかも。
とりあえず、バッチ更新を使う意味はあまりなさそうだという結果が得られてし
まいました。
--
海老原 雄一郎 / EBIHARA, Yuichiro
Email: ebihara @ iplocks.co.jp
pgsql-jp メーリングリストの案内