コミットされた並列順次スキャン

以前の記事で、PostgreSQL 9.5でロックされている並列シーケンシャルスキャンの取得について書きました。 しかし、それは起こりませんでした。 ただし、PostgreSQL 9.6の次期リリースのPostgreSQLのmasterブランチへの最初の並列シーケンシャルスキャンコミットについて喜んでお伝えします。



PostgreSQLの並列クエリは長い間私の夢でしたが、数年前から取り組んでいます。 開発はPostgreSQL 9.4リリースサイクルから始まりました。バックグラウンドで動作する動的ワーカーと動的共有メモリを追加しました。その開発はPostgreSQL 9.5で継続され、今日コミットされた並行性の基本インフラストラクチャを追加するというアイデアがありました。 今日のコミットと次に行われる作業について少しお話ししたいと思います。







しかし、私が最初にすることは、私が借りている人に感謝することです。 まず、プロジェクトの完了に多大な貢献をしたアミット・カピラ。 2人で大量のコードを作成し、この機能の本格的な一部となりました。 そして、このコードの一部は、過去数年にわたって多くのコミットを経てきました。 また、コミットに含まれない大量のコードを作成しました。 第二に、このプロジェクトの初期段階で私を助けてくれたノア・ミッシュに感謝します。 第三に、PostgreSQLコミュニティと、レビューとテストのパッチをサポートしてくれた個人、改善案、そして私たちをさまざまな方法でサポートしてくれた多くの人々に感謝したいと思います。



EnterpriseDB、特にその管理に感謝することも重要です。 まず、トム・キンケイドとマーク・リンスター。 彼らのサポートがなければ、私とAmmitがこのプロジェクトに多くの時間を費やすことはできません。また、EnterpriseDBの私のチームがいなければ、他の作業上の問題を解決する必要があるたびに辛抱強く私を助けてくれませんでした。 みんなありがとう。



次に、デモの時間です。

rhaas=# \timing Timing is on. rhaas=# select * from pgbench_accounts where filler like '%a%'; aid | bid | abalance | filler -----+-----+----------+-------- (0 rows) Time: 743.061 ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 rhaas=# set max_parallel_degree = 4; SET Time: 0.270 ms rhaas=# select * from pgbench_accounts where filler like '%a%'; aid | bid | abalance | filler -----+-----+----------+-------- (0 rows) Time: 213.412 ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

計画は次のようになります。

 rhaas=# explain (costs off) select * from pgbench_accounts where filler like '%a%'; QUERY PLAN --------------------------------------------- Gather Number of Workers: 4 -> Parallel Seq Scan on pgbench_accounts Filter: (filler ~~ '%a%'::text) (4 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

蓄積ノードはすべてのワーカーを収集し、すべてのワーカーは追加プランで並行して起動されます。 追加の並列Seqスキャンプランは通常のSeqスキャンであるためです。 関係する各ブロックが1回だけスキャンされるように、ワーカーは互いに調整されます。 各ワーカーは最終結果セットのサブセットを生成でき、収集ノードはすべてから結果を収集します。



現在の実装の大きな制限の1つは、Parallel Seq Scanノードの上にノードコレクタを生成することです。 つまり、この関数は、ノード間で追加できるため、継承階層（テーブルの共有パーティションを使用）では現在機能していません。 現時点では、結合をプッシュしてワーカーにプッシュすることもできません。 インフラストラクチャエグゼキューターは各タイプのプランの起動をサポートしていますが、現在のスケジューラーはこれをサポートするにはバカすぎます。 9.6リリースサイクルが終了する前に、この問題を修正したいと考えています。 現在の状況を考えると、この機能を使用すると、インデックスを追加しても効果がなくなり、少数のワーカーを追加しても実行速度が向上するという利点があります。



私の経験では、通常、数人の労働者を追加することは助けになり、その利点は多数の労働者にうまく対応できないと言っています。 なぜこれが起こっているのか、どのように改善するのかを理解するためにより深い研究も必要です...ご覧のとおり、5人の労働者でさえ生産性をかなり改善できますが、これは以前の制限ほど重要ではありません。 ただし、CPUの数はこれまでずっと増加しているため、それらをさらに改善したいと思います。



結論として、この関数を完全に終了した基本的な形式でも呼び出す前に、完了する必要がある特定のタスクがいくつかあることに注意したいと思います。 まだエラーがある可能性があります。 テストは大歓迎です。 pgsql-hackersとpostgresql.orgでテストするときに発見した問題を報告してください。 ありがとう