PostgreSQLのVACUUM

本屋さんに行ってPostgreSQLの本を探した。

PostgreSQL徹底入門 第3版

この本を買おうかな〜と迷いつつ、とりあえずVACUUM機能のところだけ読んで棚に戻したww

追記型・多版型同時実行制御(MVCC)

PostgreSQLは追記型のデータ管理をしている。
Wikipediaを見れば書いてあるけど、つまり更新を行う際、
ひとつのレコードをそれぞれのトランザクションで共有するのではなく、
全部別々のレコードとして保持しておいて、最も正しい状態のものだけをアクティブにしておくやり方。
(古い更新データは全部削除マークをつけて管理する。)
これをMutiple Version Concurrency Control(多版型同時実行制御)というらしい。

VACUUMはゴミデータをゴミ箱に移動させるイメージ

こういう風に何でも物理的に消去しないとどんどんデータファイルは肥大化して、
削除マークがついたがいっぱい入っている状態は無駄なので、
VACUUMという文を実行してFree Space Map（FSM）という領域に返す。
FSMに入ったデータはゴミなので、普通にSELECT文を実行したときとかは引っかからない。
FSMはデスクトップOSの「ゴミ箱」みたいなものみたい。
ただ、ちょっと違うのは、次から更新が入ってきたときはまずFSMからメモリを取るらしい。

FSMを解放する為にはVACUUM FULLかCLUSTER文を実行する

FSMに占有されたメモリが大きくなりすぎたらVACUUM FULLかCLUSTER文を実行してOSにメモリを返す。
VACUUM FULLとCLUSTERはどちらもFSMをクリアして、かつインデックスを再作成する。
両者の違いはCLUSTER文には最初の1回めはインデックスの名前を指定すること？
(ごめんなさい、この辺いい加減な理解です..)

ちなみにインデックスを再作成するだけならばREINDEXという文がちゃんとある。
あと、VACUUM FULLもCLUSTERも、実行中はそのテーブルに対して排他ロックをかけるっぽい。
(SELECT文さえも実行できないということ)

最近のPostgreSQL(Ver.9)は自動VACUUM機能がある

昔のPostgreSQLはVACUUMを手動で実行しなければならなかったらしい。
でも最近のバージョンでは設定ファイルに閾値を定義しておけばそれを超えたときに自動でVACUUMしてくれるそうだ。
あと、昔はスキーマ全体でひとつのFSMを持っていたけど、テーブルごとにFSMを持つよう改められたらしい。
[ThinkIT] 第3回：VACUUMの活用によるチューニング (1/2)

最近のPostgreSQLはレプリケーションもできるようになったらしい。
あと、昔からPostgreSQLはxmlを列として保持して、SELECT文でxpathで検索できるんだって！
MySQLばっかり使っていたけど、これは熱い！覚えよう！！

僕がとってもためになるな〜と思ったページ

http://www.geocities.jp/sugachan1973/doc/funto60.html
ここのページにPostgreSQLの仕組みがとっても詳しく解説されている。
何か、著者の人は自分のことを「事務員さん」って言っているけど、本当なのかなぁ？
プログラマなんじゃないかって思ってしまうくらい丁寧に、解らないことがあったら全部調べて解説してくれている。
職業はプログラマじゃなくてもプログラマの魂は持っている人なのかもしれない。