The EDB Blog
April 10, 2017

The list of new features coming in PostgreSQL 10 is extremely impressive.  I've been involved in the PostgreSQL project since the 8.4 release cycle (2008-2009), and I've never seen anything like this.  Many people have already blogged about these features elsewhere; my purpose here is just to bring together a list of the features that, in my opinion, are the biggest new things that we can expect to see in PostgreSQL 10. 

[免責情報: (1) 他に意見を異にする第三者もあります。(2) リリース前に取り下げられるパッチもある事は、あり得ない事ではありません。(3) 次に示すリストは PostgreSQL のコミュニティ全体の作業を代表するものであり、具体的に私自身あるいは EnterpriseDB 社のものではなく、また私は第三者の仕事を承認する意図を持つものではありません。

基本機能

宣言型パーティショニング PostgreSQL の先のバージョンでは、PostgreSQL はテーブルパーティショニングをシミュレートしたテーブル継承のみをサポートしていましたが、設定が複雑なのとパフォーマンス特性があまり優れたものではありませんでした。PostgreSQL 10 では、パーティショニングのリストや範囲を専用のシンタックスで決定でき、INSERT のパフォーマンスも画期的に改善しました。 将来のリリースではパフォーマンスの改良やこれまでになかった機能の追加などにさらに多くの作業が行われますが、(私見では)すでに v10 にある機能だけでも大進歩と言えると思います。

論理的リプリケーション PostgreSQL には、バージョン 9.0 以来、ストリーミング リプリケーションと呼ばれる事もある物理的リプリケーション方法がありましたが、これにはデータベース全体を複製する必要があり、スタンバイサーバー上で任意の形式に書き込むことは許されておらず、異なるバージョンやデータベースシステムに渡って複製を行いたい場合は、使いようのないものでした。PostgreSQL はバージョン 9.4 以来、基本的には変更補足である、論理的デコーディングを持っており、大人気博しましたが、ある種のアドオンなしでは複製には使えませんでした。PostgreSQL 10 では設定が容易でテーブル粒度に機能する論理的リプリケーション機能を追加し、明らかに大きな前進を遂げました。 これは最初にデータをコピーした後、その後の期日まで保存するものです。

改良された並列クエリー PostgreSQL 9.6 でも並列クエリーを提供していましたが、その機能は PostgreSQL 10 では Parallel Bitmap Heap Scan や Parallel Index Scan などの新機能を持つなど大幅に改良されました。 並列クエリーでは2倍から4倍のスピードアップは当然で、他の改善点とあいまって、スピードアップが広範なクエリーに適用される事となります。

SCRAM 認証 PostgreSQL はKerberos、SSPI、そして SSL 証明認証方式を含む非常に多くの各種認証方式を提供し、高いセキュリティを期しています。 しかし、ユーザーとしては単に PostgreSQL 自体が管理するパスワードのみを使いたい場合があります。 既存のリリースでは、これは回線上にユーザーが提供したパスワードを送るだけのパスワード認証形式を使用して行うか、回線上にハッシュおよびソルトされたバージョンのパスワードを送る md5 認証形式で行ってきました。 その後のアプローチではデータベースからハッシュされたパスワードを盗んだり、回線上でスニッフする事は、プリイメージが計算できなくともパスワード自体を盗む事と同等となっています。 PostgreSQL 10 では scram 認証を導入しており、特に SCRAM-SHA-256 はより安全な認証となっています。nbspサーバーがディスクに保存する情報であれ認証交換の内容であれ、クライアントになりすますのに十分ではないのです。 もちろん、MD5 が SHA-256 に置き換えられたことは大きな改善です。  マイケル・パキアのこのトピックのブログも参照してください。1つだけ注意すべき事は、libpq を使わない限りは、この機能はあなたの特定のクライアントドライバーが SCRAM をサポートするためにアップデートされない限り使用できないため、この機能が全面的に利用可能になるまでには少し時間がかかると思います。

エクスキューター速度アップ 表式と targetlist プロジェクションの速度アップのために、PostgreSQL エクスキューターの大部分が書き換えられましたが、将来のリリースでは JIT (ジャストインタイム) コンパイルが追加される予定です。 ハッシュアグリゲーションがより効率の高いハッシュテーブルを使用するよう、またその中により狭いタプルを保存できるよう書き換えられ、複数アグリゲートを計算するクエリーの高速化、および1面が一意と証明できる結合の高速化の作業も実行されました。グルーピングセットがハッシュアグリゲーションをサポートできるようになりました。 PostgreSQL はすべてのリリースで少なくとも複数のパフォーマンス改善を行っていますが、表式と targetlist プロジェクションの書き換えは、多くのユーザーに利益を与える特に大規模かつ重要な改善となります。

永続的なハッシュインデックス PostgreSQL のハッシュインデックスは長年放置の憂き目にさらされてきましたが、状況は v10 で著しく改善されます。 最も注目すべき変更は今やハッシュインデックスへの変更はWALに書かれる事で、クラッシュの心配がなく適切にスタンバイサーバーへ複製される事になります。 しかし、パフォーマンスと並行処理の向上のためのバケット分割アルゴリズムの練り直し、より良いパフォーマンスのためのメタページのキャッシュページアトタイム バキューミングの追加、そしてそれらをよりじっくりと拡張するのに前もって必要とされる手順を含めて、かなりの量の仕事がなされたのです。アミット・カピラは、彼らが btree インデックスをもしのいだ事例について書いています。明らかになすべき仕事がたくさんある一方で、私はそれらの改善にワクワクしています。

ICU 照合サポート 現在のリリースでは PostgreSQL はオペレーティングシステムが供給する照合機能のみに依存していますが、これが時として問題を起こす場合があります: 照合の動作が特に Linux と Windows オペレーティングシステム間で異なる場合があり、またあるオペレーティングシステムでその振る舞いが他のシステムで利用可能な紹介機能ともマッチする紹介機能を探す事は必ずしも簡単とは言えないのです。 さらに、少なくとも Red Hatでは、glibc が マイナーリリースでの OS-ネイティブの紹介機能の振舞いを定期的にぶち壊しにするため、つまりインデックス順序はもはや照合順序に一致しないがために、それが実質的に PostgreSQL のインデックスを破損させるのです。 私にとっては、一般的に使われているシステムコールの振舞いをメンテナンスリリースで変更してしまう事は、怒れるアライグマの家族を誰かの車の中に閉じ込める事とほぼ同じくらい「友好的」な事のように思われますが、一方 glibc のメンテナンス担当者たちは同意しないでしょう。 (実際、これらのインタフェースの一部を全く使用しない事を勧める議論もあります。) 一方、libicu についてはこれを大切にすると皆が言っています。

でもちょっと待ってください、まだあります!

私の見解では、上記にリストした機能はユーザーが PostgreSQL 10 に期待できる最も刺激的なものですが、9月にはリリースされると予測されています。 しかし、今回の機能満載のリリースほどでなくとも、これまでのリリースにおいて目玉機能として挙げても良かった多くの重要な機能があります。 次のそれらの一部をご紹介します:

拡張統計機能 (ndistinct機能依存性) もしクエリープランナーが行数の見積もり誤って、とんでもないクエリープランになってしまったとしたら、あなたはどうやって修正しますか? 拡張された統計によって、あなたが指定するパラメーターに応じて、追加の統計情報を集めるようシステムに命令する事ができ、それが正しいプランを得るのに役立ちます。

FDW アグリゲートプッシュダウン. これまでのリリースでは、SELECT COUNT(*) FROM foreign_table は、外部テーブルから各行をフェッチし、それらをローカルで数え上げる事によって実行されていました。 それはひどいものであって、今はそのような事はしません。

遷移表 今やステートメントによって変更可能な全行にアクセスできる、PL/pgsql AFTER STATEMENT トリガーを書く事が可能です。これは、行ごとにコールする AFTER ROW トリガーを書くより高速であり、かつより便利です。

待ち事象の改良 PostgreSQL 9.6 は待ち事象監視機能を pg_stat_activity に導入していますが限られた範囲のイベントに対してのみとなっています。 PostgreSQL 10 からは、補助プロセスと非接続バックグラウンド作業者を含めて、ラッチ待機I/O 待機を見る事ができるようになります。

新しい整合性チェックツール 今や新しい amcheck モジュールを使用して、btree インデックスの整合性を検証する事が可能です。 あなたが、新しいストレージ様式に先行書き込みログを加えようとする開発者、あるいは開発者がバグを作ったと思っているユーザーであれば、wal_consistency_checking でテストできる事をよろこんでいただけると思います。今回、pg_dump がより良いテスト範囲を持ちました。

よりスマートな接続対応 libpq による通信は複数ホストを指定する事ができ、また書き込み接続を現在受付可能なサーバーを探し出すことを要求する事も可能です。

Quorum-ベースの同期リプリケーション 柔軟性とパフォーマンスの改善のため、コミットが N台のスタンバイ同期サーバーの K でアクノリッジされなければならない事を指定する事ができます。

その他のクールな機能

本リリースでは、その他多くの機能が大幅に改良されました。 XMLTABLE は、XML データのクエリーを高速かつ簡単にします。 直接トランザクションのコミット状態を調べる事ができ、リプリケーションのトラッキングを改善しました。 psql は現在 \if ... \elseif ... \else ... \endif をサポートする事でスクリプティングを簡単にし、また、監視ツールのスーパーユーザー権限なしでの実行を可能にする新機能新ロールが設けられました。 エンコーディング変換は高速になり、またソーティングも同様です。トランザクションログをストリーミング中に圧縮できます。 そして他にもまだありますが、すでにこのブログ投稿は長くなり過ぎました。 もしあなたが PostgreSQL 10 で提供される新機能についてまだまだ知りたい場合は、このトピックのブログマイケル・パキエのものを時々 depesz してください。 どちらもここで紹介した機能の一部や、その他興味深いと思われる機能、について追加の詳細を提供しています。

最後の説明: 我々は、おそらくディレクトリ名に「log」と言う単語があるために、pg_xlog または pg_clog のディレクトリが重要なデータではないと誤って信じているユーザーについて、常に問題を持っていました。 これらのディレクトリはより明確にするために、それぞれpg_wal および pg_xact とリネームする事としました。 SQL 関数とユーティリティ名は以前は「xlog」と言う文字列を含んでおり、これはトランザクションログまたは先行書き込みログを意味していましたが、全て代わりに「wal」を使用してリネームされました。逆に、デフォルトのログディレクトリは今は pg_log ではなく log と呼ばれ、内部名と混同されないようにしました。これらの変更は一部のユーザーにとっては、恐らくはアップグレードに関して多少の痛みを伴うかもしれませんが、私たちはユーザーが破滅的な誤りを避ける事に役立つと願っています。

ここまで読んでいただいてありがとうございます! 今回のリリースは素晴らしいものになると思います。

Robert H. Haas is Vice President, Chief Database Architect, at EnterpriseDB. 

この投稿記事は、もともとRobert氏の個人的なブログに掲載されていたものです。 

 

robert.haas_enterprisedb.comの写真

Robert is Chief Architect, Database Server, employed at EnterpriseDB as well as a PostgreSQL Committer. Robert is an expert in OLTP query tuning, schema design, triggers and stored procedures, and internals development, as well as an experienced UNIX/Linux system administrator. Additionally,...