[pgsql-jp: 28476] Re: updateの性能を向上

[Yasuo Ohgaki]

大垣です。

# 推測へ、さらに推測を重ねます :)

Tamotsu Ebina wrote:
> 正確に測定していませんが、
> pg_config.h の BLCKSZ を16Kにするとランダムの更新処理は逆に遅くなりませんか?
> こちらでのテストではバッチ的な連続insert処理では速くなりましたがランダム更新は
> 時間測定できていません。

たしかに、遅くなる可能性はありますね。

> 一般的な話ですが、バッファサイズが大きくなれば
> ランダムの検索・更新処理は遅くなりますよね？

そうとも言えないと思います。
PostgreSQLの場合、OSのファイルシステムを使っているので同じ
OS/ファイルシステム/データベースでもファイルシステムの構成で
早くなったり、遅くなったりする事が考えられます。

大昔のファイルシステムはほとんどの場合、1ブロックは1KBでした
が、今のファイルシステムはもっと大きいブロックサイズを使ってい
て、4KBがデフォルトになっている事が多いと思います。

# ちなみに私のLinux/XFS/40GBのパーティションは4KBでした。
# 最近のファイルシステムはブロックサイズに64KBくらいまでは指定
# できると思います。（と思ってXFSのマニュアルを見ると、XFSも
# 64KBまでサポートしているのですが、Linuxではメモリページサ
# イズしかサポートしていないようですね。Kernelソースを変更して
# ページサイズを変えれば、簡単に増やせる？

また、ディスクデバイスから読み込む場合、READ AHEAD機能を使っ
て、先読みしている場合が多いと思います。

> 8kと言う値が今までの経験値から
> 「いろいろな場合に最適と言うことでデフォルト値になっている」はず
> と勝手に考え、私の方は元に戻しました。

本家MLの内容からすると、「前から8Kだから今も8K」と言った内容に
思えました。

最適な構成はシステム毎に異なると思いますが、極端な例では、ファイ
ルシステムのブロックサイズが32KB以上なのにPostgreSQLは8KBと
言う構成の場合、PostgreSQLのブロックサイズを32KBにしてパフォー
マンスが落ちる、と言う事は考えられず、逆にパフォーマンスは向上す
る可能性が高いと考えられます。
# 特に大きいテキストを扱っている場合。

何か見落としているかもしれませんが、OSのファイルシステム管理(最
近のファイルシステムは良く知りませんが :)の仕組みからすると大き
めのブロックサイズの方が性能的には有利な場合が多いと思います。
PostgreSQLのレコードロックやインデックスのロックはページ（ブロッ
ク）ごとロックです？もし、ページ全体をロックする場合、ブロックサ
イズを大きくすると同時実行性が犠牲になりますね。

何事も用途に応じたバランスが重要なので大きければ良いと言う物では
無いですが、最近のシステムでは32KBが大き過ぎると言う事はあまりな
いと思います。

色々パラメータを変えてベンチマークするとはっきりしますが、残念な
がら今は時間がありません。

--
Yasuo Ohgaki