TECH BLOG
技術ブログ

前回（wal_buffers の効果を検証(1)）に引き続き、本記事でも wal_buffers の効果を検証した結果を記載していきます。

検証内容

今回は wal_buffers の値が UPDATE の実行速度にどの程度影響を与えるかを確認しました。
具体的には wal_buffers が -1 のときと 16 MB のときで、どれだけ UPDATE の実行時間が変わるか、というようなことを調べました。

環境は前回と同じく

• Ubuntu 22.04.1 LTS
• PostgreSQL 14.6

です。

検証手順

テスト用に no と text_value の二つのカラムをもつテーブルを用意して、wal_buffers の値を変動させながら、そのテーブルに対して UPDATE を行った際の実行時間を計測しました。

用意したテスト用のテーブル

テスト用のテーブルを作成する DDL は下記のようなものとなります。

CREATE TABLE test_table (no NUMERIC(10, 0), text_value TEXT);

• no は NUMERIC 型
• text_value は TEXT 型
  • text_value には 1 KB の文字列を格納しています。

例えば、1 MB のデータ更新を発生させたい場合には 1024 レコードを UPDATE しました。4 MB のデータ更新を発生させたい場合には 4096 レコードを UPDATEしました。
というのを繰り返して、それぞれのデータサイズごとに UPDATE の実行時間を計測しました。

検証結果

検証した結果をグラフ化したものが下記となります。

折れ線が多くて少しごちゃついていますが、グラフの説明は下記となります。

• 縦軸が UPDATE の実行時間
  • 単位は ms（ミリ秒）です。
• 横軸が UPDATE したデータサイズ
  • 単位は MB です。
• グラフの折れ線が wal_buffers
  • -1, 1 MB, 2 MB, 4 MB, 8 MB, 16 MB, 32 MB, 64 MB, 128 MB, 512 MB の 9 パターンです。

検証結果から分かったこと

結果のグラフから

1. UPDATE のデータサイズが 16 MB までは、UPDATE の実行時間もそれほどバラつかず、UPDATE のデータサイズが 32 MB を超えたあたりから、少しずつ UPDATE の実行時間がバラつき始めているように見えます。
2. UPDATE のデータサイズが大きくなるにつれて、wal_buffers が 32 MB 以下と 64 MB 以上で、実行時間の偏りがあるようです。

ということが読み取れました。

公式ドキュメントのとおり、wal_buffers に 32 MB を超える値を設定しても効果がない（どころか、逆に遅くなる）ということが分かりました。
また、wal_buffers が -1 や 16 MB、32 MB の場合では、特別に実行速度が変動するということは見られませんので、基本的には wal_buffers に -1 を設定しておいて問題なさそうです。

最後に

wal_buffers について、長々と調べましたが結局のところ -1 を設定しておけば問題ない、という結論になりました。
とはいえ、「効果を測定するために、どのような検証を行うか」というのを考えることで、そのことに対する理解が深まりますので、分かりきったことでも（余裕があれば）検証してみるのもよいですね。