Postgres-XL9.6の新機能

過去数か月間、2ndQuadrantはPostgreSQL 9.6をPostgres-XLにマージする作業を行ってきましたが、これはさまざまな理由で非常に困難であることが判明し、いくつかの侵襲的なアップストリームの変更のために当初の計画よりも時間がかかりました。興味がある場合は、こちらの公式リポジトリをご覧ください（今のところ「マスター」ブランチをご覧ください）。

アップストリームからの残りのビットのマージ、既知のバグやリグレッションの失敗の修正、テストなど、まだかなりの作業が必要です。Postgres-XLへの貢献を検討している場合、これは理想的な機会です（私に電子メールで、最初のステップをお手伝いします。

しかし、全体として、Postgres-XL 9.6は、多くの重要な分野で明らかに大きな前進です。

Postgres-XL9.6の新機能

では、Postgres-XLがPostgreSQL 9.6からどのような新機能を統合するのでしょうか？上流のリリースノートを簡単に指摘できます。XLでサポートされていない機能に関連するものを除いて、ほとんどの改善はXL9.6に直接適用されます。

PostgreSQL 9.6での主なユーザーに見える改善は、明らかに並列クエリであり、これはPostgres-XL9.6にも当てはまります。

ノード内並列処理

PostgreSQL 9.6より前は、Postgres-XLは並列クエリを取得する方法の1つでした（同じマシンに複数のPostgres-XLノードを配置することにより）。 PostgreSQL 9.6以降、これは不要になりましたが、Postgres-XLがノード内並列処理機能を取得することも意味します。

比較のために、これはPostgres-XL 9.5で可能にしたことです。クエリを複数のデータノードに分散しますが、各データノードはプレーンなPostgreSQLと同様に、「クエリごとに1つのバックエンド」の制限を受けていました。

PostgreSQL 9.6並列クエリ機能のおかげで、Postgres-XL9.6はこれを実行できるようになりました。

つまり、各データノードは、アップストリームの並列クエリインフラストラクチャを使用して、クエリの一部を並列に実行できるようになりました。これは素晴らしいことであり、分析ワークロードに関してはPostgres-XLをはるかに強力にします。

フォークの保守

いくつかの理由から、この統合は当初の予想よりも困難であることが判明したと述べました。

まず、フォークを維持することは一般的に困難です。特に、アップストリームプロジェクトがPostgreSQLと同じくらい速く動いている場合はなおさらです。フォークに固有の機能を開発する必要があります。そのため、フォークはそもそも存在します。しかし、あなたはまた上流に追いつきたいです、さもなければあなたは絶望的に遅れます。そのため、既存のフォークの一部は引き続きPostgreSQL 8.xにとどまり、それ以降にコミットされたすべての機能が失われています。

次に、以前のすべてのマージ（9.5、9.2、…）と同様に、マージは1つの大きな塊で行われました。つまり、すべてのアップストリームコミットが単一のgitmergeコマンドでマージされました。これは、回帰テストの実行などは言うまでもなく、コードがコンパイルさえされない範囲で、多くのマージ競合を引き起こすことがかなり保証されています。

したがって、修正の最初のバッチはコンパイル可能な状態にすることであり、次のバッチはすぐにセグメント障害なしで実際に実行することであり、最後に「通常の」修正が開始されます（回帰テストの実行、問題の修正、すすぎ、繰り返し） 。

これらの複雑さはフォークのメンテナンスに固有のものです（そして、おそらくさらに別のフォークを開始することを再検討し、代わりにPostgresおよび/またはPostgres-XLのいずれかに直接貢献する必要がある理由）。

ただし、影響を大幅に減らす方法があります。たとえば、次のマージ（PostgreSQL 10を使用）を小さなチャンクで実行する予定です。これにより、マージの競合の範囲が最小限に抑えられ、障害をはるかに迅速に解決できるようになります。

PostgreSQLに近い

興味深いことに、アップストリームからの並列処理を採用することで、XLコードベースから多くのコードを取り除くこともできました。この典型的な例は、XL固有のコードを簡単に置き換える並列集約コードです。

XLコードに大きな影響を与えたアップストリームの変更のもう1つの例は、9.6開発サイクルの後半にプッシュされた上位プランナーの「パス化」です。これは非常に侵襲的な変更であることが判明しました（実際、多くの未解決のバグがそれに関連している可能性があります）が、最終的には計画コードを簡素化できました（結果の計画を微調整するのではなく、基本的に適切なパスを構築します）。

マージによってXLコードを単純化し、PostgreSQLに近づけることができたと言うとき、それはどういう意味ですか？変更を定量化する最も簡単な方法は、一致するアップストリームブランチに対して「gitdiff –stat」を実行し、数値を比較することです。 9.5および9.6ブランチの場合、結果は次のようになります。

明らかに、9.6のマージにより、アップストリームに対するデルタが大幅に減少します（合計で約14％）。この違いはどこから来るのですか？

まず、その削減の一部は、本物のコードの単純化によるものです。この代表的な例は並列集計です。これは、元のPostgres-XL実装をほぼ1：1で置き換えたものです。そのため、これを取り除いて、代わりにアップストリーム実装を使用します。将来的にはそのような場所をもっと見つけて、独自の実装を維持するのではなく、上流の実装を使用したいと考えています。

第二に、多くの削減はデッドコードの削除によるものです。コードの一部のデッド/到達不能ビットを削減しただけでなく、コンパイルさえされていないかなりの数のソースファイルなども発見しました。

次は？

この時点で、PostgreSQL9.6がマスターから分割された場所であるb5bce6c1までの変更をマージしました。したがって、PostgreSQL 9.6.2に追いつくには、9.6ブランチの残りの変更をマージする必要があります。ほとんどの場合バグ修正があるはずだと考えると、それは完全なマージと比較して（うまくいけば）かなり単純な作業になるはずです。

もちろん、バグはあります。実際、この時点でまだいくつかの失敗した回帰テストがあります。 XL 9.6の公式リリースを行う前に、これを修正する必要があります。さらにテストを行う必要があるため、Postgres-XLのサポートに関心がある場合は、これは非常に有益です。

私たちがよく耳にする迷惑の1つは、パッケージ、またはパッケージの欠如です。利用可能な最後のパッケージがかなり古く、.rpmだけがあり、他には何もないことに気付いたかもしれません。これに対処し、複数のフレーバー（.rpmや.debなど）の最新パッケージの提供を開始する予定です。

また、開発プロセスへの貢献と参加を容易にするために、開発プロセスの編成方法にいくつかの変更を加える予定です。これは、実際には9.6ブランチとは関係のない別のトピックなので、数日中に詳細を投稿します。