PGECons成果報告会が開催されました

5月20日，PostgreSQLエンタープライズ・コンソーシアム（PGECons）の成果発表セミナーが開催されました。今年のセミナーも昨年と同様にオンライン開催となり，約150名の聴講エントリがあったようです。昨年の報告でも同じことを書きましたが，通常の会場開催の場合に催される打ち上げ懇親会は，残念ながら今年もおあずけでした。懇親会はOSSコミュニティ活動の大事な一部分です。来年こそは再開できることを願います。

PGEConsは，技術部会の3つのワーキンググループ（WG）が技術的な検証活動などを行っており，他に広報部会とCR（Community Relations）部会があります。今年も技術部会の3つのWGとCR部会から密度の高い調査・検証成果が発表されました。

以下に発表された活動成果の概要を紹介しますが，幅の広い多数のテーマで，高密度のものばかりです。ここで詳しく紹介することは叶いません。詳細についてはすでに公開している発表スライドをご参照いただければと思います。また，成果報告書についてもこの記事が公開される頃には，PGEConsのWebサイトから参照いただけるようになると思います。

バージョン間での性能比較

新技術検証WG（WG1）のSRA OSS, Inc. 日本支社 佐藤友章さんから，メニーコアCPUでのバージョン13と14の性能比較検証が報告されました。これは，PGEConsの恒例の活動である定点観測として行われた検証です。

検証に用いた環境はAmazon Web Service上で，DBサーバのスペックはCPUコア数が32，メモリが128GiB，測定にはpgbenchを用いています。また検証に使用した設定内容（postgresq.conf）の詳細も示されています。

検証結果ですが，参照系ではバージョン14の方がわずかに（2％ほど）性能が悪くなる結果となっています。更新系ではバージョンによる性能差はほとんど無い結果が示されました。参照系での若干の性能差が出た理由の解明にも挑んでいます。FlameGraph（フレームグラフ）を表示させることにより，index_fech_heap関数の部分で差が出ていることが示されました。このindex_fech_heap関数ですが，バージョン14では共有バッファアクセスの品質改善がされていて，それに伴うオーバヘッドが若干増えたと推察されるとのこと。

なお，この処理は更新処理でも影響はあるはずなのですが，アクセスするデータ量が参照系ほど多くないので影響が小さかったのだろうということです。ちなみに，FlameGraphとは，処理を実行されるときに呼び出される関数の処理に掛かった時間を積み上げたグラフで，炎のように見えるので「Flame」と名付けられているのだと発表の中で説明されていました。

なお，以前はWindowsでも性能を検証していましたが，今回は手が回らずできなかった様です。是非一緒に活動してくれるメンバを増やしたいとのことです。

拡張機能開発ことはじめ

課題検討WG（WG3）の日鉄ソリューションズ株式会社，永井光さんから，PostgreSQLの拡張機能の開発手順や，今回の検証で行った開発の経緯が紹介されました。ちょっと珍しい内容ですが，それだけ価値ある発表だと感じます。拡張機能の開発に挑戦される方が増えるきっかけになるのではないかと思います。

前半は，拡張機能開発の基本手順の説明です。ここではHookを用いて既存の拡張機能であるauto_explainの機能を変更することを例に説明されました。HookはPostgreSQL内で共有されているポインタで，ここに独自関数の呼び出しを割り込ませることができます。

なお，パブリッククライドサービスで用意されたPaaSとしてのPostgreSQLの場合には，ベンダ側が用意した拡張機能しか使えない場合が多いので要注意だそうです。拡張機能を独自に開発する際に作成するのは，controlファイル，SQLファイル（CREATE EXTENSIONの際に実行されるSQL⁠）⁠，Cファイル（C言語で実装されたプログラム⁠）⁠，Makefileの4種類。Amazon EC2で拡張機能組み込みを実施した場合のサンプルファイルの内容と，実施手順の例が示されました。

後半は，auto_explainの改造（魔改造？）に挑戦する報告です。開発したものを実行してみると実行計画のテーブルへのINSERT時にエラーが起こってしまうといった問題も経験し，gdbでステップ実行しながら原因究明をしたとのこと。拡張機能の作り方はわかってしまえば難しくはなさそうですが，役に立つ機能を実装するためには独特な制約もある様で，挑戦される方には今回の報告は参考になるでしょう。

shared_buffersの適正値

同じく課題検討WG（WG3）のヤマトシステム開発株式会社（所属：ヤマト運輸株式会社）鳥居英明さんから，バッファサイズを指定するパラメータであるshared_buffersの値をどの様にするのが良いのかの調査と検証結果が報告されました。

PGEConsが2019年度に実施した「機械学習を用いたPostgreSQLパラメータのチューニング検証」で得られた最適値はシステムメモリの50%でした。しかし，PostgreSQLマニュアル（13.1）ではシステムメモリに40%以上割り当てても性能は向上しないと書かれています。開発コミュニティのマニュアルではシステムメモリの25%が妥当な初期値だとされています。そこで検証によって設定方針を見つけようというのが，今回の検証のスタートだったようです。

検証環境は，システムメモリ16GBに対して，shared_buffersの値を4GB，8GB，12GB（25％:小，50％:中，75％:大）として検証しています。PostgreSQLのバッファ戦略として，OSのページキャッシュもDBのバッファの延長として考えています。

ではここから検証結果を要約します。読み込み，書き込み，並行実行性では，個別の検証ケース毎に，性能が良いのがサイズ大（75％）の場合だったりサイズ小（25％）だったりとなるケースもあるものの，全般的には影響は小さいか，または影響なしという結果でした。ところが，メモリ利用効率ではバッファサイズの影響が大きく表れていました。サイズ中（つまりDBバッファが50％の場合で，結果としてOSキャッシュもおよそ50％）の場合は，最悪の場合には同じデータがバッファとキャッシュの両方に重複して載ってしまって最も効率が悪い状態になります。このメモリ効率が悪いサイズ中（50％）の場合が，性能的にも早くに性能低下が始まっていました。 ただ，この性能検証結果は，どんな条件の場合でもこれと同じ結果になるというものではないことに留意が必要でしょう。この記事の報告では省略していますが，OSのページキャッシュ活用のメリットやデメリット，PostgreSQLのデータキャッシュアーキテクチャやバッファマネージャについての仕組みについても報告されています。単に検証結果だけを憶えるのではなくて，仕組みを理解した上で結果を理解するべきものです（簡単ではありませんが⁠）⁠。是非，報告書の本編を参照いただいて理解をしていただきたいと思います。

PostgreSQLへの移行手引き

移行WG（WG2）のNECソリューションイノベータ株式会社 黒澤彰さん，富士通Japan株式会社 多田明弘さんから，2021年リリースのPostgreSQL 14を踏まえて，これまでの移行WGの成果物との違いや注意点などについて報告されました。

移行WGでは，2017年度成果発表会にて「移行のポイントや注意点」として商用DBからPostgreSQLの移行の現実が報告されました。このときのPostgreSQLのバージョンは9.5が対象でした。そのときの報告と現在のPostgreSQL 14ではいろいろな差異が出てきています。

たとえば，パラレルクエリは9.6で追加されましたが，バージョンが上がるとパラレルクエリが使えるケースが増えているなど，機能が単に追加されただけではなく，機能レベルが上がってきています。仕様面から見ると，異種DBMSとの比較では基本的には仕様の差は残っていて，それらの仕様の違いが互換性の無い点として残っています。

また，「⁠PostgreSQL自習書」がレベルアップされました。第1版の作成時に「DB技術者の移行」（⁠既存のシステムで設計・開発・運用をしてきた移行元のDB技術者からPostgreSQLの技術者に技術者自身が移行してもらうこと）がコンセプトでした。このコンセプトを踏襲しつつ，第2版では「商用運用」と「移行」を重点にレベルアップされており，ミッションクリティカルな要件に対応する運用管理ノウハウの拡充や，「⁠トラブル時の調査手順」の新章の追加などがされています。また，「⁠Oracle技術者のためのPostgreSQL自習書」の名称の通り，Oracleからの移行注意点を拡充したものになっています。

開発コミュニティとのリレーションでの取り組み ―IVM機能の開発支援

CR（Community Relations）部会を代表してSRA OSS, Inc. 日本支社 石井達夫さんから部会で行った活動のいくつかが報告されました。CR部会の目的は，エンタープライズ領域へのPostgreSQLの適用に向けて，グローバルで進められている開発コミュニティに技術的課題をフィードバックすることです。開発コミュニティとしてもユーザ企業の声が聞けるメリットがあり，両者の橋渡しをする役割をCR部会が担っています。

発表ではCR部会の活動として3項目が紹介されましたが，この記事ではIVM（Incremental View Maintenance）機能の開発を支援する活動についてお知らせします。IVMとは，マテリアライズドビューをリアルタイムで高速に更新する機能です。この機能をPostgreSQL開発コミュニティに提案中で，CR部会メンバー企業がレビューに参加するなどして本体組み込みのIVM開発を支援しているそうです。残念ながら次期のPostgreSQL 15（2022年冬リリース予定）には入らないことになりましたが，本体への組み込みではなく拡張モジュールとしてリリースすることになりました。この拡張モジュールが「pg_ivm」です。

pg_ivmはコミュニテイに提案しているIVMの機能を拡張モジュールとして実装したもので，現状のPostgreSQLでもIVMを利用したいとの声がありました。このpg_ivmを使ってもらうことを通じて，IVMへの理解やフィードバックが得られることを期待しているとのことです。現状では機能制約があり，使用できるSELECTは，内部結合，外部結合，DISTINCTに限られ，集約は未対応になっています。今後は対応可能バージョンを増やし，また，使用できるSELECT文も増やしていきたいとのことです。