Existen varios parámetros de configuración que pueden hacer que el planificador de consultas no genere un plan de consulta en paralelo bajo ninguna circunstancia. Para que se puedan generar planes de consulta en paralelo, las siguientes configuraciones deben estar definidas como se indica.
max_parallel_workers_per_gather debe establecerse en un
valor mayor que cero. Este es un caso especial del principio más general de que no
se deben usar más trabajadores que el número configurado a través de
max_parallel_workers_per_gather.
Además, el sistema no debe estar ejecutándose en modo de usuario único (single-user mode). Dado que todo el sistema de base de datos se está ejecutando como un único proceso en esta situación, no habrá trabajadores en segundo plano disponibles.
Incluso cuando en general sea posible generar planes de consulta en paralelo, el planificador no los generará para una consulta dada si se cumple alguna de las siguientes condiciones:
La consulta escribe datos o bloquea filas de la base de datos. Si una consulta contiene
una operación de modificación de datos, ya sea en el nivel superior o dentro de una
CTE, no se generarán planes paralelos para esa consulta. Como excepción, los siguientes
comandos, que crean una nueva tabla y la completan, pueden usar un plan paralelo para la
parte SELECT subyacente de la consulta:
CREATE TABLE ... AS
SELECT INTO
CREATE MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
La consulta podría suspenderse durante la ejecución. En cualquier situación en la que el
sistema considere que podría ocurrir una ejecución parcial o incremental, no se genera
ningún plan paralelo. Por ejemplo, un cursor creado usando
DECLARE CURSOR nunca usará un plan paralelo. Del mismo
modo, un bucle PL/pgSQL de la forma FOR x IN query LOOP .. END LOOP nunca
usará un plan paralelo, porque el sistema de consultas en paralelo no puede verificar que
el código en el bucle sea seguro de ejecutar mientras la consulta paralela está activa.
La consulta utiliza alguna función marcada como PARALLEL UNSAFE.
La mayoría de las funciones definidas por el sistema son PARALLEL SAFE,
pero las funciones definidas por el usuario están marcadas como PARALLEL
UNSAFE por defecto. Consulta la discusión sobre
Section 15.4.
La consulta se está ejecutando dentro de otra consulta que ya es paralela. Por ejemplo, si una función llamada por una consulta en paralelo emite ella misma una consulta SQL, esa consulta interna nunca usará un plan paralelo. Esta es una limitación de la implementación actual, pero puede que no sea deseable eliminar esta limitación, ya que podría resultar en que una sola consulta use una cantidad enorme de procesos.
Incluso cuando se genera un plan de consulta en paralelo para una consulta en particular,
existen varias circunstancias bajo las cuales será imposible ejecutar ese plan en paralelo en
el momento de la ejecución. Si esto ocurre, el líder ejecutará la parte del plan por debajo
del nodo Gather completamente por sí mismo, casi como si el nodo
Gather no estuviera presente. Esto sucederá si se cumple alguna de las
siguientes condiciones:
No se pueden obtener trabajadores en segundo plano debido a la limitación de que el número total de trabajadores en segundo plano no puede superar max_worker_processes.
No se pueden obtener trabajadores en segundo plano debido a la limitación de que el número total de trabajadores en segundo plano iniciados para fines de consultas en paralelo no puede superar max_parallel_workers.
El cliente envía un mensaje Execute con un recuento de obtención (fetch count) distinto de cero. Consulta la discusión sobre el protocolo de consulta extendido. Dado que libpq actualmente no proporciona ninguna forma de enviar dicho mensaje, esto solo puede ocurrir cuando se usa un cliente que no dependa de libpq. Si esto ocurre con frecuencia, puede ser una buena idea establecer max_parallel_workers_per_gather en cero en las sesiones donde sea probable, para evitar generar planes de consulta que puedan ser subóptimos cuando se ejecuten en serie.