Prácticas recomendadas para consultas paralelas en Aurora PostgreSQL

La ejecución de consultas paralelas es una característica de PostgreSQL que permite dividir una sola consulta SQL en tareas más pequeñas que se procesan simultáneamente mediante varios procesos de trabajo en segundo plano. En lugar de ejecutar una consulta por completo en un único proceso de backend, PostgreSQL puede distribuir partes de la consulta, como análisis, uniones, agregaciones o clasificación, en varios núcleos de CPU. El proceso líder coordina esta ejecución y recopila los resultados de los trabajadores paralelos.

Sin embargo, para la mayoría de las cargas de trabajo de producción, especialmente para los sistemas OLTP de alta concurrencia, recomendamos desactivar la ejecución automática de consultas en paralelo. Aunque el paralelismo puede acelerar las consultas en grandes conjuntos de datos en las cargas de trabajo de análisis o elaboración de informes, presenta riesgos importantes que, a menudo, superan los beneficios en entornos de producción muy ajetreados.

La ejecución paralela también supone una sobrecarga significativa. Cada servidor paralelo es un proceso completo de backend de PostgreSQL, que requiere la bifurcación del proceso (copiar las estructuras de la memoria e inicializar el estado del proceso) y la autenticación (consumir los espacios de conexión hasta el límite max_connections). Cada trabajador también consume su propia memoria, incluso work_mem para las operaciones de clasificación y cifrado, con varios trabajadores por consulta, el uso de la memoria se multiplica rápidamente (por ejemplo, 4 trabajadores × 64 MB work_mem = 256 MB por consulta). Como resultado, las consultas paralelas pueden consumir considerablemente más recursos del sistema que las consultas de un solo proceso. Si no se ajustan correctamente, pueden provocar una saturación de la CPU (varios trabajadores abruman la capacidad de procesamiento disponible), un aumento del cambio de contexto (el sistema operativo cambia con frecuencia entre varios procesos de trabajo, lo que aumenta la sobrecarga y reduce el rendimiento) o el agotamiento de la conexión (dado que cada trabajador paralelo consume una ranura de conexión, una sola consulta con 4 trabajadores utiliza 5 conexiones en total, 1 líder + 4 trabajadores, lo que puede agotar rápidamente el grupo de conexiones con una alta concurrencia, lo que impide nuevas conexiones de clientes y provoca errores en las aplicaciones). Estos problemas son particularmente graves en cargas de trabajo de alta concurrencia en las que varias consultas pueden intentar ejecutarse en paralelo simultáneamente.

PostgreSQL decide si utilizar el paralelismo en función de las estimaciones de costos. En algunos casos, el planificador puede cambiar automáticamente a un plan paralelo si parece más económico, incluso cuando no es lo ideal en la práctica. Esto puede suceder si las estadísticas de los índices están desactualizadas o si la sobrecarga hace que los análisis secuenciales parezcan más atractivos que las búsquedas de índices. Debido a este comportamiento, los planes paralelos automáticos a veces pueden presentar regresiones en el rendimiento de las consultas o en la estabilidad del sistema.

Para aprovechar al máximo las consultas paralelas en Aurora PostgreSQL, es importante probarlas y ajustarlas en función de la carga de trabajo, supervisar el impacto en el sistema y desactivar la selección automática de planes paralelos en favor del control por consulta.

Parámetros de configuración

PostgreSQL utiliza varios parámetros para controlar el comportamiento y la disponibilidad de las consultas paralelas. Comprenderlos y ajustarlos es fundamental para lograr un rendimiento predecible:

Consideraciones clave

Identificación del uso de consultas paralelas

Las consultas pueden pasar a planes paralelos en función de la distribución de datos o las estadísticas. Por ejemplo:

SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';

Esta consulta puede usar un índice para datos recientes, pero cambiar a un análisis secuencial paralelo para datos históricos.

Puede registrar los planes de ejecución de consultas cargando el módulo auto_explain. Para obtener más información, consulte Logging execution plans of queries (Registro de los planes de ejecución de las consultas) en el centro de conocimiento de AWS.

Puede supervisar los planes de ejecución de consultas en la instancia de base de datos de Aurora PostgreSQL para detectar los planes de ejecución que contribuyen a la carga actual de la base de datos y realizar un seguimiento de las estadísticas de rendimiento de los planes de ejecución a lo largo del tiempo mediante el parámetro aurora_compute_plan_id. Para obtener más información, consulte Supervisión de planes de ejecución de consultas y máximo de memoria para Aurora PostgreSQL

Puede supervisar la Información sobre las bases de datos de CloudWatch para detectar eventos de espera relacionados con consultas paralelas. Obtención de más información sobre los eventos de espera relacionados con consultas paralelas, mediante Eventos de espera de IPC:parallel

A partir de la versión 18 de PostgreSQL, puede supervisar la actividad de los trabajadores en paralelo mediante columnas nuevas en pg_stat_database y pg_stat_statements:

Estas métricas ayudan a identificar las discrepancias entre el paralelismo planificado y el real, lo que puede indicar limitaciones de recursos o problemas de configuración. Utilice las siguientes consultas para supervisar la ejecución paralela:

Para las métricas de trabajadores paralelos por base de datos:

SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();

Para las métricas de trabajadores paralelos por consulta

SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;

Cómo controlar el paralelismo

Existen varias formas de controlar el paralelismo de consultas, cada una diseñada para diferentes escenarios y requisitos.

Para desactivar el paralelismo automático de forma global, modifique el grupo de parámetros para establecer:

max_parallel_workers_per_gather = 0;

Para configuraciones persistentes y específicas del usuario, el comando ALTER ROLE proporciona una forma de establecer los parámetros que se aplicarán a todas las sesiones futuras de un usuario en particular.

Por ejemplo:

ALTER ROLE username SET max_parallel_workers_per_gather = 4; garantiza que cada vez que este usuario se conecte a la base de datos, sus sesiones utilizarán esta configuración de trabajo paralelo cuando sea necesario.

El control por sesión se puede lograr mediante el comando SET, que modifica los parámetros durante la sesión de la base de datos actual. Esto resulta especialmente útil cuando se deben ajustar temporalmente los ajustes sin que ello afecte a otros usuarios o sesiones futuras. Una vez configurados, estos parámetros permanecen en vigor hasta que se restablezcan explícitamente o hasta que finalice la sesión. Los comandos son sencillos:

SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;

Para un control aún más detallado, SET LOCAL permite modificar los parámetros de una sola transacción. Esto resulta ideal cuando se necesita ajustar la configuración para un conjunto específico de consultas dentro de una transacción, tras lo cual la configuración vuelve automáticamente a sus valores anteriores. Este enfoque ayuda a evitar efectos no deseados en otras operaciones de la misma sesión.

Uso de la administración de planes de consulta (QPM)

En Aurora PostgreSQL, la característica de administración de planes de consulta (QPM) está diseñada para garantizar la adaptabilidad y la estabilidad de los planes, independientemente de los cambios en el entorno de la base de datos que puedan causar la regresión del plan de consulta. Para obtener más información, consulte Información general de la administración de planes de consultas de Aurora PostgreSQL. La QPM aporta cierto control sobre el optimizador. Revise los planes aprobados en QPM para asegurarse de que se ajusten a la configuración de paralelismo actual. Actualice o elimine los planes obsoletos que puedan estar forzando una ejecución paralela poco óptima.

También puede corregir los planes con pg_hint_plan. Para obtener más información, consulte Corrección de planes mediante pg_hint_plan. Puede utilizar la sugerencia denominada Parallel para forzar la ejecución paralela. Para obtener más información, consulte Sugerencias para planes paralelos.

Diagnóstico del comportamiento de consultas paralelas

Se usa EXPLAIN (ANALYZE, VERBOSE) para confirmar si una consulta utilizó la ejecución paralela:

Para desactivar temporalmente el paralelismo para la comparación:

SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;
RESET max_parallel_workers_per_gather;