As operações a seguir são sempre restritas em paralelo.
- Varreduras de expressões de tabela comuns (CTEs).
- Varreduras de tabelas temporárias.
- ...
Mais abaixo na mesma página de manual:
[...] Da mesma forma, as funções devem ser marcadas
PARALLEL RESTRICTED
se acessarem tabelas temporárias, estado de conexão do cliente, cursores, instruções preparadas ou estado local de back-end diverso que o sistema não pode sincronizar entre os trabalhadores. Por exemplo,setseed
erandom
são paralelas restritas por este último motivo.
Nenhuma menção a CTEs. Agora não tenho certeza se posso usar PARALLEL SAFE
para funções que contêm um CTE. Faria sentido para mim que esses fossem apenas PARALLEL RESTRICTED
.
Contexto: Eu tenho que determinar o melhor rótulo para funções definidas pelo usuário existentes. A configuração é nova desde o Postgres 9.6, e pode ter um grande impacto no desempenho, pois as operações que envolvem funções que não são não PARALLEL SAFE
serão executadas por trabalhadores paralelos, PARALLEL RESTRICTED
apenas pelo líder. (E PARALLEL USAFE
desativa o paralelismo completamente.)
Eu postei uma pergunta relacionada em pgsql-general .
Se uma função contém uma consulta que usa um CTE e essa função é usada por um processo de trabalho paralelo, a consulta e o CTE só serão executados no contexto de processo privado do trabalhador paralelo. Não há estado compartilhado envolvido na criação ou verificação desse CTE.
Portanto, é seguro marcar a função
PARALLEL SAFE
.A citação da documentação diz que um CTE definido em uma consulta que deve ser paralelizada só pode ser escaneado pelo processo líder, não pelos trabalhadores paralelos, justamente pelo fato de que o CTE não é compartilhado entre os processos. Isso não tem impacto nas CTEs definidas em consultas executadas em funções chamadas por trabalhadores paralelos, porque essas consultas aninhadas não serão paralelizadas de qualquer maneira :