2006年9月21日，待望のPostgreSQL 8.2のベータ版がリリースされ，PostgreSQL8.2の全容が明らかとなった。全体的にはそれほど目だった新機能はないが，細かな改善や，性能向上がなされているようだ。
本連載でも25回と30回で8.2の新機能や改良点を取り上げてきたが，それを簡単に復習してみよう。
25回では，CE(Constraint Exclususion)という，継承を使ったテーブルパーティショニング機能の改良，pg_freespacemapの追加を紹介した。また，ソート処理とディスク上のビットマップを使ったVACUMMの高速化への試みについても紹介した。残念ながらVACUUMの高速化は盛り込まれなかったが，ソート処理の高速化は8.2に取り込まれた。
30回では，GINという新しいインデックスタイプの追加，COPYやINSERTの改良について紹介した。
本稿ではこれらで言及しなかった8.2での新機能や改良点を紹介していこう。
バッファ管理の改良によるマルチCPU環境での高速化
PostgreSQL 8.1では，画期的な性能向上が達成された。これは，共有メモリー上のバッファ管理のアルゴリズムを改良したことによるものである。また，従来性能が向上しなかった4 CPU以上でのシステムでもほぼCPU数に比例した性能向上が得られている(本連載の16回と23回を参照)。
PostgreSQL 8.1では，ロック粒度の細分化と，clock sweepアルゴリズムの採用によって高速化が達成されていた。PostgreSQL 8.2では，更に改良が加えられ，バッファとディスクページの対応を決めるデータ構造へのロック(BufMappingLock)を16個の個別のロックに細分化した。これにより，バッファ 割り当て待ちの競合が減り，性能が向上した。
PostgreSQLメーリングリストでの報告によれば，20%ほどの向上があったとのことである。
PostgreSQL 8.1では，確かに4 CPUや8 CPUでの性能向上があったが，12 CPU以上では性能が向上しないことが報告されている(IPA OSS iPediaのPostgreSQL性能評価結果)。今回の改良により，その問題も払拭されていると思われる。
現状では実際に8以上のCPUを使ったシステムでPostgreSQLを運用している例は少ないであろうが，今後マルチコアやクアッドコアのシステムが導入されるにつれ，PostgreSQL 8.2の実力が評価されるようになるかもしれない。
ソート処理の高速化
ソート処理はORDER BYなどの明示的なソート処理で使われるだけでなく，DISTINCT文や結合処理におけるマージジョイン，インデックスの構築の際など広範囲で使われるので，実用上重要である。DBにおけるソート処理では，データ量が大きいため。すべてをメモリーの中で処理するのは無理である。そのため，ディスク上の作業ファイルをうまく使ってソート処理を行う必要がある。
PostgreSQL 8.2では，ディスクを使ってソートする際に，ソートにつかう作業ファイルの数を動的に決定してソート処理を高速化した。従来は作業ファイルの数は7に固定されていたが，開発者は，作業メモリー(work_mem)に応じて作業ファイル数を決定する方が効率がよいと考えたようだ。
