15.1. 병렬 쿼리 작동 원리

옵티마이저가 특정 쿼리의 빠른 실행을 위해 병렬 처리를 할 때, 아래와 같이 Gather node를 포함하여 실행계획을 세운다:

EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
                                     QUERY PLAN                                      
-------------------------------------------------------------------------------------
 Gather  (cost=1000.00..217018.43 rows=1 width=97)
   Workers Planned: 2
   ->  Parallel Seq Scan on pgbench_accounts  (cost=0.00..216018.33 rows=1 width=97)
         Filter: (filler ~~ '%x%'::text)
(4 rows)

위 실행 계획 경우, Gather 노드는 병렬로 실행되는 계획에 정확히 하나의 하위 계획을 갖는다. Gather 노드가 실행 계획 트리의 맨 위에 있는 경우 모든 쿼리는 병렬로 실행된다. 실행 계획 트리에 어딘 가에 (Gather 노드가) 있다면, 일부 쿼리만 병렬로 실행된다. 위의 예에서 하나의 테이블만을 접근하는 쿼리는 Gather 노드 외에 하나의 실행 계획만 있다; 실행 계획 노드는 Gather 노드의 하위 실행 계획으로 병렬로 실행 된다.

EXPLAN 명령 사용하기를 통해서, 플래너가 선택한 작업자의 수를 확인할 수 있다. Gather 노드가 쿼리를 실행할 때, 사용자 세션은 백그라운드 작업자 프로세스 수와 플래너가 선택한 작업자 수와 동일한 프로세스가 요청된다. 한 번에 존재할 수 있는 백그라운드 작업자의 수는 max_worker_processes 설정값에 의해 제한되므로, 병렬 쿼리가 계획된 작업자보다 적거나 작업자 없이 실행될 수 있다. 최적의 계획은 사용 가능한 작업자 수에 따라 달라질 수 있으므로 쿼리 성능이 저하 될 수 있다. 이런 현상이 빈번한 경우 max_worker_processes 설정값을 늘리면 더 많은 작업자가 동시에 실행되거나 max_parallel_workers_per_gather 설정값을 줄여 플래너가 더 적은 수의 작업자를 요청할 수 있다.

모든 백그라운드 작업 프로세스는 Gather 노드의 일부로 실행계획으로 병렬 쿼리를 실행한다. 리더는 또한 실행계획의 일부를 실행하긴 하지만 추가적인 책임이 있다: 작업자가 생성한 모든 튜플을 읽어야만 한다. 적은 수의 튜블에 의해 병렬처리 실행계획이 생성될 때, 쿼리 속도를 빠르게 하기 위해 리더는 종종 추가적인 작업자처럼 행동한다. 이와 반대로, 많은 수의 튜블을 처리하는 실행계획이 생성될 때 리더는 작업자에 의해 생성된 튜블을 읽고, Gather 노드 레벨 이상의 실행계획에서 필요한 추가적인 작업 처리한다. 이러한 경우, 리더는 실행계획의 병렬 처리 부분을 거의 수행하지 않는다.