PostgreSQL 8.1は順調に開発が続いており，既に「フィーチャーフリーズ」(新たに機能を追加しない)フェーズに入っている。この後は9月位にベータ・リリース，年内には正式リリースとなる見込みが高くなった。
前回お伝えしたように，8.1で追加された機能の最大の目玉は2相コミットだが，それ以外にも興味深い機能や性能向上がなされている。今回はその中からまだ紹介していなかったものをいくつかとりあげよう。
autovacuumの本体への取り込み
autovacuumは，contribモジュールの一つとして提供されており，データベースの状態を判断して自動的にVACUUMを実行する自立したサーバーである。
PostgreSQLは実行性能を維持するためには，VACUUMの実行が欠かせない。反面，VACUUMの適切な実行間隔や実行頻度をどの程度にするかは実際に運用するデータベースの規模やアクセス頻度に大きく影響されるため，最適値の決定が難しいという問題もあった。
こうした問題を解決するのがautovacuumである。autovacuumは，PostgreSQLの実行統計情報を参照することにより，最適なタイミングでVACUUMを自動実行する。例えば，更新や削除が多くなってきたらVACUUMを起動する，などということが可能である。autovacuumを適切に利用することにより，熟練したデータベースの管理者がいない状況でもPostgreSQLの適切な運用が可能になる。
今回autovacuumがcontribモジュールから正式にPostgreSQL本体に取り込まれることにより，わざわざcontribモジュールをインストールすることなくautovacuumが利用できるようになった。
PostgreSQL 8.1では，autovacuumはチェックポイント・プロセスやバックグラウンド・ライター・プロセスと同様，postmasterから起動される。したがって，通常通りpostmasterを起動してostgreSQLを運用開始するだけでautovacuumが実行できることになる。
ただ，今のところデフォルトではautovacuumは起動されない設定になっている。autovacuumを起動するためには，postgresql.confの
#autovacuum = false # enable autovacuum subprocess?
を
autovacuum = true # enable autovacuum subprocess?
に変更してpostmasterを再起動する。
autovacuumが起動されても，実行統計情報の収集機能が有効になっていなければVACUUM処理が行われない。実行統計情報の収集機能を有効するには，postgresql.confの
#stats_row_level = off
を
stats_row_level = on
にしてpostmasterを再起動する。
autovacuumの設定
autovcuumの挙動を制御するために，以下の項目がpostgresql.confに追加された。
表1●postgresql.confのautovcuum設定項目
| 設定項目 | デフォルト値 | 説明 |
| autovacuum | FALSE | trueならばautovacuumを有効にする |
| autovacuum_naptime | 60 | autovacuumを起動する間隔を秒単位で指定 |
| autovacuum_vacuum_threshold | 1000 | VACUUMを起動するトリガとなる更新行数 |
| autovacuum_analyze_threshold | 500 | ANALYZEを起動するトリガとなる更新行数 |
| autovacuum_vacuum_scale_factor | 0.4 | VACUUMを起動するトリガとなる更新行数の割合 |
| autovacuum_analyze_scale_factor | 0.2 | ANALYZEを起動するトリガとなる更新行数の割合 |
autovacuumの効果
|
| 図1●autovacuumの効果 |
いつものように，縦軸はTPS(Transaction Per Second)で，1秒間に実行したトランザクション数を示す。したがって数字が大きいほど性能が良いことになる。横軸はpgbenchの実行回数である。pgbenchは以下のように起動した。
pgbench -n -c 10 -t 500
同時接続数は10で，それぞれの接続ごとに500個の更新トランザクションを実行する。したがって，1回のpgbenchの起動でトータル5000回のトランザクションが実行される。
autovacuumが有効な場合は，多少性能にでこぼこはあるものの，100TPS前後の性能を維持していることが分かる。
一方autovacuumが有効になっていない場合は，徐々に性能が低下し，最終的には当初の半分程度の性能になってしまった。これは，更新が行われることによってテーブルに不要領域が溜っていくからである。このデータからもVACUUMの必要性が分かる。
PostgreSQLに対する誤解で最も多いものの一つが，「PostgreSQLは使っていくうちに性能が低下する」というものである。VACUUMを適切に実行していないケースではこうした誤解が生じる。VACUUMはPostgreSQL 固有の操作であり，特に他のDBから移行してきたユーザーにとってはVACUUMが落とし穴になり易いのも事実である。autovacuumが正式にサポートされたことにより，こうした誤解や運用ミスが少くなることが期待される。
ただ，autovacuumを使用するにあたっては実行統計情報の取得自体に一定のオーバヘッドがあることに注意したい。環境にもよるが，筆者の経験では，10-20%程度性能への影響が見られた。
ではautovacuumが使えないかというと，まったく逆である。VACUUMを適切に運用できない場合，性能の低下は20%どころではなく，ときには50%以上にもなる。熟練したPostgreSQL管理者を用意できないような環境では，autovacuumを使って一定の性能を維持できるメリットは非常に大きいと言える。
次に，ローカル・バッファとマルチカラム・インデックス，テーブル・パーティショニングを紹介しよう。
