UNLOGGED TABLEによるCOPY性能向上効果

9.1から入ったCREATE TABLE文のUNLOGGEDオプションはWALを出力しないということらしいので、通常のテーブルへのCOPYよりも高速になるはずなんだけど、実際、どのくらい変わってくるのかを実感するために簡単に測定してみた。

今回は別件の調査も兼ねて、XML型のデータをロードしてみることにする。XML型の場合はXMLのパース処理が重そうなので、通常の型よりはUNLOGGEDによる効果は低くなりそうだが・・・

測定環境

とりあえず手元にある環境を使って簡単に測定してみる。

HW	ないしょ
Memory	16GB
OS	RH 5.3
PostgreSQL	9.1.1

PostgreSQLの設定は殆ど弄らずに測定。変更したのは以下のみ。

パラメータ	設定値	備考
wal_buffers	4MB	デフォルトは32KB
checkpoint_segments	100	デフォルトは3
logging_collector	on	ログファイル出力
log_directory	/tmp/pg_log	ログの出力先
log_min_duration_statement	0	サーバログにCOPYの処理時間を出すため

COPY対象のテーブルは以下のDDLで生成する。

通常テーブル

CREATE TABLE orders (
  data xml
);
TRUNCATE TABLE orders;

UNLOGGEDテーブル

CREATE UNLOGGED TABLE orders (
  data xml
);
TRUNCATE TABLE orders;

測定

測定方式

それぞれの方法で作成したテーブルにCOPY文でデータをロードし、そのCOPY文の処理時間をサーバログで確認する。
なお、ロードするXML型のデータ量は以下。

レコード数	2,592,000件
平均レコード長	393バイト
ファイルサイズ総計	1,019,597,096バイト(約1GB)

そんなに厳密な測定をするつもりはないので、測定は一発勝負で。

そういえば、1回測定ミスして分かったんだけど、COPYの背景ではXMLがWel-formedかどうかのチェックってやってないように思える・・・
間違えてフラットデータをXML型にロードしようとしたら、ロードできちゃったんだよな・・・いいのかな・・・。

測定結果

通常のテーブル	56872.047 (ms)
UNLOGGEDテーブル	50955.64 (ms)

まとめ

UNLOGGEDテーブルにした場合、COPY文は10%程度の性能向上効果が見込めそう？
- もう少し高いのかなと思ったらそうでもない。逆に言えば、WAL書き込みが全体処理に及ぼす影響は思ったよりも大きくないということかも。
今回はXML型を使ったので(パース時間がそれなりに重いと仮定して)、通常のデータタイプならもう少し向上するかも・・・と思ってたけど、COPY背景ではWel-formedなチェックをしていないんだとすると、パースの問題じゃないってことか？
COPY先のテーブルへの更新がなく、かつ入力ファイルのバックアップを保持するのであれば、クラッシュしても復元は出来るので、そういう用途であればUNLOGGEDテーブルを使う意義はありそう？

Permalink | コメント(1) | トラックバック(0) | 13:00