どのような状況でも、クエリプランナーが並列クエリプランを生成しないようにする設定がいくつかあります。 並列クエリプランを生成するには、次の設定を指定したとおりに構成する必要があります。
max_parallel_workers_per_gatherは、ゼロより大きい値に設定する必要があります。 これは、
max_parallel_workers_per_gatherで設定された数より多くのワーカーを使用しないという、より一般的な原則の特殊なケースです。
さらに、システムはシングルユーザーモードで実行してはなりません。 この状況では、データベースシステム全体が単一のプロセスとして実行されているため、バックグラウンドワーカーは利用できません。
一般的に並列クエリプランを生成することが可能な場合でも、次のいずれかが当てはまる場合、プランナは特定のクエリに対してそれらを生成しません。
クエリは、データを書き込むか、データベース行をロックします。 クエリにデータ変更操作が最上位レベルまたはCTE内に含まれている場合、そのクエリの並列プランは生成されません。 例外として、新しいテーブルを作成して入力する次のコマンドは、クエリの基になる
SELECT部分に並列プランを使用できます。テーブルを作成... ASSELECT INTO素材化ビューの作成リフレッシュ素材化ビュー
実行中にクエリが中断される場合があります。 部分的または増分的な実行が発生する可能性があるとシステムが考える状況では、並列プランは生成されません。 たとえば、DECLARE cursorを使用して作成されたカーソルは、並列プランを使用しません。 同様に、FOR x INクエリloopの形式
のPL/pgSQLループ。 END LOOPは並列プランを使用しません。並列クエリシステムは、並列クエリがアクティブである間、ループ内のコードが安全に実行できることを検証できないためです。クエリは、
PARALLEL UNSAFEとマークされた関数を使用します。 ほとんどのシステム定義関数はPARALLEL SAFEですが、ユーザー定義関数はデフォルトでPARALLEL UNSAFEとマークされます。クエリは、すでに並列である別のクエリ内で実行されています。 たとえば、並列クエリによって呼び出される関数がSQLクエリ自体を発行する場合、そのクエリは並列プランを使用しません。 これは、現在の実装の制限であるが、非常に多数のプロセスを使用する単一のクエリをもたらす可能性があるため、この制限を取り除くことは望ましくない場合がある。
特定のクエリに対して並列クエリプランが生成される場合であっても、実行時にそのプランを並列に実行することが不可能な状況がいくつかある。 これが発生すると、リーダーは、Gatherノードが存在しないかのように、プランのGatherノードの下の部分を完全に単独で実行します。 これは、次のいずれかの条件が満たされた場合に発生します。
バックグラウンドワーカーの総数がmax_worker_processesを超えることができないという制限のため、バックグラウンドワーカーは取得できません。
並列クエリの目的で起動されたバックグラウンドワーカーの総数がmax_parallel_workersを超えることができないという制限のため、バックグラウンドワーカーは取得できません。
クライアントは、ゼロ以外のフェッチカウントを持つExecuteメッセージを送信します。 拡張クエリプロトコルの説明を参照してください。 現在、libpqはそのようなメッセージを送信する方法を提供していないため、これはlibpqに依存しないクライアントを使用する場合にのみ発生します。 これが頻繁に発生する場合、max_parallel_workers_per_gatherを0に設定することをお勧めします。これにより、連続的に実行するときに次善となる可能性のあるクエリプランの生成を回避できます。