PostgreSQLの進化に迫る
SQL言語の拡張機能
PostgreSQLは当初から配列データ型やテーブル継承などの拡張機能を備えています。これに加えて、バージョン8.3になって、全文検索、XML機能が追加されました。8.4ではWINDOW関数と再帰SQL構文が追加されています。8.4の機能については次回に詳しく解説します。
配列データ型の機能とは、INTEGER型やTEXT型（PostgreSQLの長さ制限のない文字列型）などの任意のデータ型に対して、その配列をデータベースにおけるデータ型として使用できるというものです。以下のように使用します。
CREATE TABLE t_docs (id INTEGER, c_tags TEXT[]);
-- テーブルのカラムにTEXTの配列型を指定
SELECT c_tags[3] FROM t_docs;
-- 各行のカラムc_tagsの3番目要素を取り出し
SELECT * FROM t_docs WHERE 'SQL' = ANY (c_tags) ;
-- 配列カラム c_tags の要素に 'SQL' が含まれる行を選択
PostgreSQLバージョン8.2からは、上記3番目のSQLのような配列の要素を検索する場合にも使えるインデックス方式「GIN」がサポートされるようになりました。「GIN」は全文検索機能においても使用されます
テーブル継承は、PostgreSQL独特の機能です。
次のように記述すると、親テーブルのカラム定義を継承した子テーブルを作ることができます。子テーブル固有の制約やカラム定義に親テーブルの定義が加わります。
CREATE TABLE comments (id INT PRIMARY KEY, comments VARCHAR(20), date DATE);
CREATE TABLE comments2009
(PRIMARY KEY (id), CHECK (date >= '2009-01- 01')) INHERITS (comments);
親テーブルを検索すると子テーブルのデータも一緒に検索されます。テーブルパーティション（テーブル分割）を行うときに、この機能が応用されます。
図2では、データを日付の年ごとに分割して格納していますが、親テーブルを対象とすれば一つのテーブルと同じように検索のSQLを記述することができます。
バージョン8.2から8.4にかけ、継承を使ったテーブルについて、検索条件や子テーブル上の制約を元に自動的に不要な子テーブルの走査をスキップする仕組みが導入され、改良されていきました。
全文検索についてはバージョン8.3以前から、外部の全文検索エンジンを利用するモジュールが、外部プロジェクトとしていくつか公開されていました。pg_rust（RASTを使用）、Ludia（Sennaを使用）などがあります。
8.3で標準機能として追加されたものは、PostgreSQL自体に全文検索用インデックスを構築するものです。以前は「tsearch2」と呼ばれ、標準ではインストールされない「contribモジュール」という扱いでした。
この全文検索機能は単語単位でインデックスを作りますが、日本語の分かち書きをする機能は含まれていません。そのため、まず文章をMeCabなどの形態素解析ソフトウエアで分かち書きして、それを元に全文検索用インデックスを作る必要がありました。これを透過的に実行してくれる拡張モジュールtextsearch-jaが公開されています。
XMLの機能は、SQL：2003規格のSQL／XMLにのっとったものです。データ型としてXML型が使用でき、XML型のデータに対してXPathでの問い合わせができます。また、テーブルやSQL実行結果など表形式のデータをXMLにマッピングする関数が備わっています。
また、PostgreSQLは、ストアドプロシージャ（ユーザー定義関数）をサポートしていますが、その記述言語にさまざまな言語を選択できます。これはほかのデータベース製品に無い特徴かも知れません。
PL／pgSQLというOracleのPL／SQLに似た言語のほか、PL／Perl、PL／Python、PL／Tclが標準でサポートされます（ただし、別途Perl、Python、Tclを用意し、ビルド時に指定が必要）。このほか、PostgreSQLとは独立して、さまざまな言語のPostgreSQLのユーザー関数定義むけ対応モジュールが開発、配布されています。
また、PostgreSQL本体とは別個の外部プロジェクトとなりますが、PostgreSQL上に地理情報システムを構築するための拡張モジュールにPostGISがあります。PostGISは多くの実用システムで使われています。
運用機能について
PostgreSQL運用関連の改善は、VACUUMとの闘いの歴史です。マルチバージョンで行を管理する方式を採用したため多大な恩恵も受けましたが、「VACUUMをしなければいけない」という十字架も背負いました。「PostgreSQLはVACUUMがあるから」という理由で採用を見送られるパターンも、かつては多々ありました。
バージョン7.2で「コンカレントVACUUM」に対応しました。これは通常のアクセスをロック待ちさせることなく、並行にVACUUM処理ができるというものです。
今日、VACUUMといった場合は、コンカレントVACUUMのことを指します。それ以前のVACUUMは参照だけのSELECTコマンドも含め、すべてのSQLコマンドをロック待ちさせるものでした。毎日行うことが推奨されていますので、24時間稼働するシステムには適用が困難でした。この旧来のVACUUMを今日では「VACUUM FULL」と呼び、通常は実行を必要としません。
それでも定期的にVACUUMをしなければいけないという制約は残りましたので、VACUUMを実行し忘れていたので性能が悪化したというケースはなくなりません。これに対してバージョン8.1から自動VACUUM（autovacuum）が導入されました。
当初は、自動VACUUM自体の性能が必ずしも良くなかったのですが、これも順次改善されています。8.3以降では標準で自動VACUUMが稼働するようになり、負荷が高いなどで意識的に性能チューニングをする場合以外には、VACUUMを意識しなくても良いようになっています。
VACUUM以外では、バージョン8.0でアーカイブロギングができるようになったことが大きな進展です。また、このアーカイブロギングの応用として、ウォームスタンバイと呼ばれるクラスタリング構成が構築できるようになりました。
これは、WALを待機マシンに転送して、待機マシンでは常にリカバリーを続けるようにすることで、障害時にリカバリー済みの代替マシンをすぐに起動できるようにするものです。バージョン8.2からウォームスタンバイ構成を助ける諸機能が追加されるようになっています。
