15.2. 병렬 쿼리가 가능한 경우

어떤 상황에서도 쿼리 플래너가 병렬 쿼리 계획을 생성하지 못하게 하는 몇 가지 설정이 있다. 모든 병렬 쿼리 계획을 생성하려면 아래와 같이 설정을 해야 한다.

• max_parallel_workers_per_gather 설정값은 0보다 큰 수로 설정해야 한다. max_parallel_workers_per_gather에 설정한 수보다 더 많은 작업자가 사용되는 것은 특수한 경우다.

• dynamic_shared_memory_type 설정이 지정되어야 한다. 병렬 쿼리는 프로세스 협력에 데이터를 전달하기 위하여 동적 공유 메모리가 필요하다.

또한 데이터베이스 서버는 단일 사용자 모드로 실행되어서는 안된다. 전체 데이터베이스 시스템이 싱글 프로세스로 실행되기 때문에 백그라운드 작업자는 사용할 수 없다.

병렬 쿼리 계획을 생성 할 수 있는 일반적인 경우에도, 플래너는 다음 중 하나라도 해당되면 병렬 쿼리 실행 계획을 생성하지 않는다:

• 쿼리가 데이터베이스의 로우를 쓰거나 락을 발생할 경우. 최상위 레벨이나 CTE 내 수정 작업이 포함된 쿼리는 병렬 실행 계획은 세워지지 않는다. 이 제한은 개선 될 예정이다.

• 쿼리가 실행 중에 중단될 수 있는 경우, 시스템은 (쿼리가) 부분 또는 추가로 실행 가능할 수 있다고 생각하기 때문에 병렬 실행 계획이 생성되지 않는다. 예를 들어, DECLARE CURSOR 명령을 이용하여 커서를 생성한 경우, PL/pgsql의 FOR x IN 쿼리 LOOP .. END LOOP 형식과 같은 루프는 병렬 쿼리로 절대로 실행되지 않는다. 왜냐하면 병렬 쿼리 시스템은 병렬 쿼리가 실행 중일 때, 루프 내의 코드가 안전하게 실행되는 지 검증할 수 없기 때문이다.

• 쿼리가 PARALLEL UNSAFE 설정된 함수를 사용할 경우. 대부분의 시스템 함수는 PARALLEL SAFE이지만 기본값으로 사용자 정의 함수는 PARALLEL UNSAFE 설정으로 만들어진다. 이 옵션에 대한 설명은 15.4절에서 다룬다.

• 쿼리가 이미 다른 쿼리 내부에서 병렬처리로 실행될 경우. 예를 들어, 병렬 쿼리에 의해 호출된 함수가 SQL 쿼리 자체에 실행되면, 쿼리는 병렬 실행 계획을 결코 사용하지 않는다. 현재 구현에서 제한되어 있는데, 하나의 쿼리가 많은 수의 프로세스를 사용할 수 있기 때문에 이 제한은 계속 유지될 예정이다.

• 트랜잭션 격리 수준이 serializable일 경우. 아직 구현하지 못했음.

병렬 쿼리 계획이 특정 쿼리에서 생성된 경우라도 여러 상황에 따라 병렬로 쿼리가 실행되지 않는다. 이 경우 Gather 노드가 없는 것처럼 리더는 Gather 노드 아래에 있는 실행 계획 부분을 전체를 자체적으로 실행한다. 이런 경우는 다음 조건 중 하나가 충족 될 경우 발생한다.

• No background workers can be obtained because of the limitation that the total number of background workers cannot exceed max_worker_processes.

• The client sends an Execute message with a non-zero fetch count. See the discussion of the extended query protocol. Since libpq currently provides no way to send such a message, this can only occur when using a client that does not rely on libpq. If this is a frequent occurrence, it may be a good idea to set max_parallel_workers_per_gather in sessions where it is likely, so as to avoid generating query plans that may be suboptimal when run serially.

• A prepared statement is executed using a CREATE TABLE .. AS EXECUTE .. statement. This construct converts what otherwise would have been a read-only operation into a read-write operation, making it ineligible for parallel query.

• The transaction isolation level is serializable. This situation does not normally arise, because parallel query plans are not generated when the transaction isolation level is serializable. However, it can happen if the transaction isolation level is changed to serializable after the plan is generated and before it is executed.