Existem várias configurações que podem fazer com que o planejador de consulta não gere um plano com paralelismo em nenhuma circunstância. Para que seja gerado um plano com paralelismo, as configurações a seguir devem ser definidas conforme indicado:
A variável de configuração
max_parallel_workers_per_gather
deve ser definida para um valor maior que zero.
Este é um caso especial do princípio mais geral de que não devem
ser usados mais processos trabalhadores do que o número
configurado via max_parallel_workers_per_gather.
Além disso, o sistema não deve operar no modo mono-usuário. Como todo o sistema de banco de dados seria executado em um único processo nesta situação, não estaria disponível nenhum processo trabalhador em segundo plano.
Mesmo quando, em geral, é possível gerar planos com paralelismo, o planejador não os irá gerar para uma determinada consulta se alguma das seguintes condições for verdadeira:
A consulta escreve algum dado, ou bloqueia alguma linha
do banco de dados.
Se uma consulta contiver uma operação de modificação de dados
no nível superior, ou em uma CTE (Expressão de Tabela Comum),
não será gerado nenhum plano com paralelismo para esta consulta.
Como exceção, os comandos a seguir, que criam uma tabela e
a preenchem, podem usar um plano com paralelismo para a parte
da consulta SELECT subjacente:
CREATE TABLE ... AS
SELECT INTO
CREATE MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
A consulta pode ser suspensa durante a execução.
Em qualquer situação em que o sistema pense que possa ocorrer
execução parcial ou incremental, não é gerado nenhum
plano com paralelismo.
Por exemplo, um cursor criado usando
DECLARE CURSOR
nunca usará um plano com paralelismo.
Da mesma forma, um laço do PL/pgSQL da forma
FOR x IN consulta LOOP .. END LOOP nunca usará
um plano com paralelismo, porque o sistema de consulta paralelizada
não consegue verificar se o código no laço é seguro para ser
executado enquanto a consulta paralelizada estiver ativa.
A consulta usa alguma função marcada como
PARALLEL UNSAFE.
A maioria das funções definidas pelo sistema são
PARALLEL SAFE,
mas as funções definidas pelo usuário são marcadas como
PARALLEL UNSAFE por padrão.
Veja a discussão em Seção 15.4.
A consulta está sendo executada dentro de outra consulta que já está paralelizada. Por exemplo, se uma função chamada por uma consulta paralelizada emitir uma consulta SQL, esta consulta nunca usará um plano com paralelismo. Esta é uma limitação da implementação corrente, mas pode não ser desejável remover esta limitação, porque pode resultar em uma única consulta usando um número muito grande de processos.
Mesmo quando é gerado um plano com paralelismo para uma consulta específica, há várias circunstâncias em que será impossível executar este plano com paralelismo em tempo de execução. Se isto ocorrer, o líder executará a parte do plano abaixo do nó Gather inteiramente sozinho, quase como se o nó Gather não estivesse presente. Isto acontecerá se alguma das seguintes condições for atendida:
Não é possível obter processo trabalhador em segundo plano devido à limitação de que o número total de processos trabalhadores em segundo plano não pode exceder max_worker_processes.
Não é possível obter processos em segundo plano devido à limitação de que o número total de processos em segundo plano iniciados para fins de consulta paralelizada não pode exceder max_parallel_workers.
O cliente envia uma mensagem Execute com um número diferente de zero de linhas a serem recuperadas. Veja a discussão do protocolo de consulta estendido. Como a biblioteca libpq atualmente não oferece nenhuma maneira para enviar este tipo mensagem, isto só pode ocorrer ao usar um cliente que não dependa da libpq. Se isto acontecer com frequência, poderá ser uma boa ideia definir max_parallel_workers_per_gather como zero para as sessões afetadas, para evitar a geração de planos de consulta que podem ficar abaixo do ideal quando executados em série.