3.1. OracleとPostgreSQLのパラレル処理について¶

3.2. パラレル処理の機能差¶

• パラレル処理の機能差

  PostgreSQLとOracleのパラレル処理の機能差を以下表に示します。PostgreSQLの機能には一部周辺ツールも含みます。脚注も合わせて確認して下さい。

3.3. パラレル処理の指定方法¶

1. パラレル処理の指定箇所

2. パラメータの指定

3. 表、ロール、セッション、pg_dump、pg_restoreでのパラレル度指定方法例

• 表での指定方法

  pgbench_accounts表のパラレル度を3にする。

alter table pgbench_accounts set ( parallel_workers = 3 );

• ロールでの指定例

  postgresロールのmax_parallel_workers_per_gatherを4に上書きする。

alter role postgres set max_parallel_workers_per_gather = 4;

• セッションでの指定例

  当セッションのmax_parallel_workers_per_gatherを4に上書きする。

set max_parallel_workers_per_gather = 4;

• ヒント句での指定例

  pgbench_accounts表に対してのパラレル度を4にする。

/*+ Parallel(pgbench_accounts 4) */
select count(*) from pgbench_accounts;

• pg_dumpでの指定例

  test01データベースを/home/postgres/backup/test01_dディレクトリに-jオプションを使用して4並列（4つのテーブルを同時）でダンプする。

pg_dump -Fd -v -j 4 -f /home/postgres/backup/test01_d test01

• pg_restoreでの指定例

  /home/postgres/backup/test01_dのバックアップをtest01データベースに-jオプションを使用して4並列（4つのテーブルを同時）でリストアする。

pg_restore -c -v -j 4 -d test01 /home/postgres/backup/test01_d

3.4. パラレル処理の優先度¶

①基本的な指定優先度

②テーブルのパラレル度を指定した場合

例１ セッション指定のパラレル度よりテーブルのパラレル指定が低いケース

test01=# alter table pgbench_accounts set ( parallel_workers = 3 );
ALTER TABLE
test01=# set max_parallel_workers_per_gather = 4;
SET
test01=# explain select count(*) from pgbench_accounts;
                                            QUERY PLAN
------------------------------------------------------------------------------------------------------
 Finalize Aggregate  (cost=409514.48..409514.49 rows=1 width=8)
   ->  Gather  (cost=409514.16..409514.47 rows=3 width=8)
         Workers Planned: 3
         ->  Partial Aggregate  (cost=408514.16..408514.17 rows=1 width=8)
               ->  Parallel Seq Scan on pgbench_accounts  (cost=0.00..392385.13 rows=6451613 width=0)
(5 行)

例２ テーブルのパラレル指定よセッション指定のパラレル度が低いケース

test01=# alter table pgbench_accounts set ( parallel_workers = 6 );
ALTER TABLE
test01=# set max_parallel_workers_per_gather = 4;
SET
test01=# explain select count(*) from pgbench_accounts;
                                            QUERY PLAN
------------------------------------------------------------------------------------------------------
 Finalize Aggregate  (cost=391369.42..391369.43 rows=1 width=8)
   ->  Gather  (cost=391369.00..391369.41 rows=4 width=8)
         Workers Planned: 4
         ->  Partial Aggregate  (cost=390369.00..390369.01 rows=1 width=8)
               ->  Parallel Seq Scan on pgbench_accounts  (cost=0.00..377869.00 rows=5000000 width=0)
(5 行)

③テーブルのパラレル度を指定しない場合

図 3.1 テーブルサイズとパラレル度

④パラレル処理の方が早いと想定される実行計画のとき

4.1. パラレル指定方法の指針¶

• パラレル処理の全体のCPUを制限する

  
  

  データベースサーバにデータベース以外のサービスが搭載される場合、または複数のデータベースインスタンスを起動させる必要がある場合など対象のデータベースサービスだけでサーバCPUを使い切らないように制限する必要があります。具体的にはpostgresql.confでパラメータのmax_worker_processesを指定します。ただし、このパラメータの変更はインスタンスの再起動が必要となるため、運用スケジュールによるワークロード変更が必要な場合かつ運用上、再起動をしたくない場合はmax_parallel_workersで指定します（このパラメータはロールやセッションで上書き可能なため、運用ルールとして上書きしないようにするなど考慮が必要）。

  
  
• ロールのSQLで使用するCPUを制限する

  
  
  • 複数のロール（ユーザ）を使用する場合、ロールによっては高い性能要求が必要ないものもあるかもしれません。そのようなロールでのSQL実行にはCPUの割当を制限します。
  • オンライン処理で同時実行トランザクションが多く、パラレル化でCPUが枯渇するようであれば、その接続ロールではパラレル処理が動作しないようにします。
  
  
• セッション指定でCPUを確保する

  
  

  特定のバッチ処理などpostgresql.confの指定より十分なCPUを使用して性能を確保したい場合もあります。この場合はセッションで十分なCPUを割り当てられるようにします。ただし運用全体でCPUを枯渇させない考慮を合わせて行います。

  
  
• ヒント句でCPUを確保する

  
  

  セッション指定と同じ意図ですが、よりピンポイントに指定する方法です。

  
  
• 一定サイズ以上のテーブル以外はパラレル処理が動作しないようにする

  
  

  要求性能を満たせる場合はmin_parallel_table_scan_sizeやmin_parallel_index_scan_sizeを指定してパラレル処理が動作しないようにします。運用上、効果の低い処理にCPUを使用するより必要な処理にCPUを確保可能とするための処置です。

  
  

4.2. 運用上の考慮点¶

• pg_restoreでの例

  pg_restoreではアーカイブ形式がカスタム形式、ディレクトリ形式の場合にパラレル処理で復元できるとなっております。実際には以下の表のように、リストア中のそれぞれの処理でプロセスが起動します。

• 実行コマンド

  前提として、max_worker_processes=8,max_parallel_maintenance_workers=4, autovacuum_max_workers=2とします。

$ pg_restore -c -j 4 -d test01 backup/test01.dmp

• 処理起動後の前半

  4並列でコピーが実行され、終わったものはANALYZEが開始されています。

図 4.1 pg_restore処理前半のプロセス

• 処理起動後の後半

  索引作成がパラレルで動作している。この後、索引の作成が完了すればpg_restoreはANLYZEを待たずに完了する。（ただし、リストアした全てテーブルに対しANLYZEは継続して続行される。並列度か高く、リソースが枯渇しなければその分早く完了する）

図 4.2 pg_restore処理後半のプロセス

5.1. パラレル処理指定の適用方針案¶