図1●CEの効果
図1●CEの効果
[画像のクリックで拡大表示]

 これまでもベータテスト中に何回か取り上げたPostgreSQL 8.1だが,ついに11 月8日に正式リリースされた。前回のメジャーバージョンアップ(8.0)が2005年 の1月19日であったから,約10カ月でメジャーバージョンアップがなされたこ とになる(ちなみに,8.0が,その前のメジャーバージョンである7.4から14カ月以上かかってリリースされている)。まずは,PostgreSQL 8.1の開発に かかわったすべての方にお疲れ様と言いたい。

 PostgreSQL 8.1のソースは,いつものようにPostgreSQLの公式サイトから入手できる。また,同サイトではWIN32,Fedora Core,RedHat 9, RedHat Enterprise Linux AS 4.0, ES 2.1, 3.0, 4.0用のバイナリも公開されている。

日本語もドキュメントも相次いでリリース

 日本PostgreSQLユーザー会の有志の努力により,11月13日には早くも8.1のドキュ メントが翻訳,公開された。本稿でもさっそく解説のために利用させていただ いた。ドキュメントはこちらから入手可能だ。

http://www.postgresql.jp/document/pg810doc/index.html

PostgreSQL 8.1での改良点

 既に連載で何度か取り上げたPostgreSQL 8.1での改良点だが,改めて簡単に まとめておこう。変更点のすべてのリストは,上記ドキュメントの「VIII. 付 録 E. リリースノート」で参照できる。

バッファ管理の改良

 まず,共有メモリー上のバッファ管理の方法が変わり,ロックの粒度が細かくなっ て,オーバヘッドが低減した。本連載では「第16回 PostgreSQLのバッファ・ マネージャの改良」で性能測定も含めて解説を行っているので,そちらも見て いただきたい。本改良により「PostgreSQLは4 CPU以上では性能が向上しない」 という悪い評判が払拭できることが期待される。

ビットマップスキャンの実装

 動的にビットマップを生成し,効率的に検索を行うビットマップスキャンが実 装された。これにより,マルチカラムインデックスが定義されていなくてもイ ンデックスを使った効率的な検索が可能になった,また,取出すデータ件数が 多い場合でもインデックスを有効に使って高速な検索ができるようになった。

 ビットマップスキャンは,インデックスが定義されていない場合でも有効に働 くことがある。ただし,そのためにはメモリー上にビットマップを作ることがで きる充分な余裕が必要である。postgresql.confの work_mem の設定に注意し よう。

 ビットマップスキャンについては,「第17回 新しい実行プラン・タイプによ るPostgreSQL 8.1の性能向上」で詳しく触れている。

マルチカラムインデックスの有効利用

 列a1, a2, a3をつないで作ったマルチカラムインデックスにおいて,従来インデッ クスが利用されなかった,

WHERE a2 = 100;
WHERE a1 = 100 AND a3 = 200;

 のようなパターンでもインデックスが使われるようになった。詳細は「第19回 ベータ・リリースを間近に控えたPostgreSQL 8.1」を参照のこと。

集約関数の高速化

 count, sum, avgなどの集約関数のオーバヘッドが軽減され,筆者の実測では 最高50%近く実行が高速化されたケースもあった。詳細は「第21回 ベータ・テ ストもいよいよ佳境,PostgreSQL 8.1の便利な新機能」を参照いただきたい。

min/maxでのインデックスの利用

 インデックスがあれば,min/maxでインデックスが自動的に利用されるように なった。詳細は「第17回 新しい実行プラン・タイプによるPostgreSQL 8.1の 性能向上」に書いたので参考にしてほしい。

2相コミットの実装

 2相コミット(two phase commit)は,複数のデータベースをまたがるトランザ クションを安全に扱うことのできる機能で,分散データベースのサポートには 必須の機能だ。今回追加された機能の中ではもっと大きなもので,PostgreSQL 8.1の目玉と言えよう。2相コミットについては,「第18回 ついに2相コミット 実装!」で詳解している。

ロールの実装

 ロールとは,簡単に言うと従来のPostgreSQLでの「ユーザー」と「グループ」を 統合する概念である。ロールの導入により,従来よりもきめ細かなアクセス制 御ができるようになる。

共有行ロックの実装

 8.1以前は,行ロックは排他モードのみであったが,8.1では共有行ロックも利 用できるようになった。特に外部キー利用時に不必要な排他的行ロックがかか らなくなり,トランザクションの同時実行性や,デッドロックの可能性が減る などの効果がある。

 ロールと共有行ロックについては,「第20回 PostgreSQL 8.1ベータ・テスト 開始,新機能ロールと共有行ロック」を見ていただきたい。

 なお,筆者は行ロックを表示する関数「pgrowlocks」を公開している。行ロッ クに関する情報を見たいというニーズは以前からあったが,PostgreSQL本体には そうした機能はなかった。そこで今回「pgrowlocks」を作った次第である。ち なみに,pgrowlocksを作るためには,PostgreSQLの内部関数の一部のインター フェイスを公開したり,追加する必要があった。つまり,8.1開発中に必要な ものを組み込むことにより,pgrowlocksが8.1が動くようになったわけである。 このあたりの柔軟さがオープンソースの良いところだ。

pgrowlocksは

ftp://ftp.sra.co.jp/pub/cmd/postgres/pgrowlocks/pgrowlocks-1.0.tar.gz

で入手できる。

自動VACUUM

 ご存じのように,PostgreSQLでは追記式の記憶管理を採用している関係上, VACUUMというガーベジコレクションコマンドの定期的な実行が不可欠だ。しか し,このVACUUMの実行頻度を決めるのは結構難しく,頻繁すぎても,逆に間が 開きすぎてもパフォーマンスを損なってしまう。そこで今回正式に組み込まれ たのが自動VACUUM(autovauum)である。autovacuumを使用することにより,あ まりVACUUMを意識しなくても最適(と思われる)ときにVACUUMが行われるので, 管理の手間がかなり減ると思われる。

Constraint Exclusionによるテーブルパーティショニング

 PostgreSQLにはテーブルを継承する機能があり,これを使ってテーブルを物理 的に分割する「テーブルパーティショニング」が可能である。しかし,従来は 分割したテーブルのうち,アクセスの必要なものとそうでないものを区別する ことができず,無駄なディスクアクセスが発生していた。今回実装された Constraint Exclusionは(CE),本当に必要なテーブルだけでアクセスすること が可能であり,場合によっては飛躍的な性能の向上が見込める。

 自動VACUUMとConstraint Exclusionの詳細については,「第19回 ベータ・リ リースを間近に控えたPostgreSQL 8.1」を参照されたい。

 次に,正式公開された8.1の実力を測定してみた。