どうも、村上です。

久々の登場です。

これから何回かPostgreSQL9.2の機能である「Index Only Scan」について書いていきたいと思います。

以前はIBMのDB2というDBMSを6年ほど触っており、ここ1年半ぐらいはPostgreSQLをやっております。
なんで、少しPostgreSQLについてわかってきた(？)感じなんで、ちょいと書こうかなっていう軽いノリです。
よかったら読んで下さい。

Index Only Scan の前にいろいろと

Index Only Scanですが、PostgreSQLにとっては最近追加された目新しい機能ですが、他のDBMSでは割りと普通にある機能です。
内容を単に説明するだけでは面白くないので、なぜPostgreSQLでは実装が難しかったのかとか実際使ってみるといろいろと不思議なことが起きたので、そこら辺を交えて書きたいと思います。
まず、今回はIndex Only Scanを理解するために必要なPostgreSQLの性質をいくつか紹介します。

追記型アーキテクチャ

PostgreSQLを使い出して一番良く聞く単語が「バキューム(vacuum)」です。
DB2を使ってた時も表の再編成(REORG)、統計情報の更新(RUNSTATS)をやっててたので、そんなイメージで使ってましたけど、全然違いましたね。。。

PostgreSQLは追記型のアーキテクチャを採用しています。
つまり、データを削除(DELETE)する時は、物理的に削除するのではなく、削除フラグを立てて論理的に削除します。
また、データの更新(UPDATE)の時は、物理データにアップデートするのではなく、削除(DELETE)と挿入(INSERT)を行い論理的に更新します。

こうなってくると頻繁に削除や更新が行われるテーブルは論理的には行数が同じでも、物理的なサイズはどんどん大きくなってしまいます。
これを綺麗にしてくれるのがバキュームです。

バキュームを行うことで対象テーブルの不要領域を回収してくれます。

VACUUMは不要領域に対して、空き領域の印を付けます。その後、データがInsertされた場合は、その空き領域にデータが挿入されます。
VACUUM FULLは不要領域を削除してデータをつめていきます。そして、新たにデータがInsertされた場合は、末尾にデータが挿入されます。
物理領域を減らしたい場合はVACUUM FULLをするのが良いのですが、VACUUM FULLには排他ロックを必要とするため稼働中にはできません。

まとめ

今回は

• PostgreSQLは「追記型アーキテクチャ」を採用している
• バキューム重要

ということです。

バキューム処理って遅くないの？とか追記型の場合、インデックスはどうなるの？
とか疑問が出てくると思います。
その辺りは次回以降に書きたいと思います。

追記型アーキテクチャ
バキューム　　　　　← いまココ
Visibility Map
プラン演算子
Index Only Scan