# Optimización del rendimiento de las consultas en Aurora PostgreSQL Optimizar el rendimiento de las consultas es fundamental porque ayuda a que las bases de datos se ejecuten de forma más rápida y eficiente, a la vez que se utilizan menos recursos, lo que se traduce en una mejor experiencia de usuario y en menores costos operativos. Amazon Aurora PostgreSQL ofrece varias características que ayudan a optimizar el rendimiento de las consultas para las cargas de trabajo de PostgreSQL. **Topics** + [Mejora del rendimiento de las consultas de Aurora PostgreSQL con lecturas optimizadas de Aurora](AuroraPostgreSQL.optimized.reads.md) + [Optimización de subconsultas correlacionadas en Aurora PostgreSQL](apg-correlated-subquery.md) + [Mejora del rendimiento de las consultas mediante la unión adaptativa](user-apg-adaptive-join.md) + [Uso de caché compartida de planes](apg-shared-plan-cache.md) # Mejora del rendimiento de las consultas de Aurora PostgreSQL con lecturas optimizadas de Aurora Puede conseguir un procesamiento de consultas más rápido para Aurora PostgreSQL con las lecturas optimizadas de Aurora. Una instancia de la base de datos Aurora PostgreSQL que utiliza las lecturas optimizadas de Aurora ofrece una reducción de la latencia de las consultas de hasta 8 veces y un ahorro de costes de hasta el 30 % para aplicaciones con conjuntos de datos de gran tamaño que superan la capacidad de memoria de una instancia de base de datos. **Topics** + [Información general de las lecturas optimizadas de Aurora en PostgreSQL](#AuroraPostgreSQL.optimized.reads.overview) + [Uso de lecturas optimizadas de Aurora](#AuroraPostgreSQL.optimized.reads.using) + [Casos de uso de lecturas optimizadas de Aurora](#AuroraPostgreSQL.optimized.reads.usecases) + [Supervisión de instancias de base de datos que utilizan lecturas optimizadas de Aurora](#AuroraPostgreSQL.optimized.reads.monitoring) + [Prácticas recomendadas para lecturas optimizadas de Aurora](#AuroraPostgreSQL.optimized.reads.bestpractices) ## Información general de las lecturas optimizadas de Aurora en PostgreSQL Las lecturas optimizadas de Aurora están disponibles de forma predeterminada cuando se crea un clúster de base de datos que utiliza instancias R6gd basadas en Graviton, R8gd e instancias R6id basadas en Intel con almacenamiento de memoria no volátil exprés (NVMe). Está disponible a partir de las siguientes versiones de PostgreSQL: + versiones 14.12 y superiores, 15.7 y versiones superiores, 16.3 y versiones superiores, 17.4 y versiones superiores para instancias R8gd + versiones 14.9 y superiores, 15.4 y versiones superiores, 16.1 y versiones superiores para instancias R6gd y R6id Las lecturas optimizadas de Aurora admiten dos capacidades: caché por niveles y objetos temporales. **Caché por niveles habilitada para lecturas optimizadas**: con la caché por niveles, puede multiplicar por 5 la capacidad de almacenamiento en caché de la instancia de base de datos. De este modo, la caché se mantiene automáticamente con los datos más recientes y coherentes a nivel de transacción, lo que libera a las aplicaciones de la sobrecarga que supone administrar la vigencia de los datos en soluciones de almacenamiento en caché externas basadas en conjuntos de resultados. Ofrece una latencia hasta 8 veces mejor para las consultas que anteriormente obtenían datos del almacenamiento de Aurora. En Aurora, el valor de `shared_buffers` en el grupo de parámetros predeterminado suele estar establecido en torno al 75 % de la memoria disponible. Sin embargo, para los tipos de instancia r8gd, r6gd y r6id, Aurora reduce el espacio de `shared_buffers` un 4,5 % para alojar los metadatos de la caché de lecturas optimizadas. **Objetos temporales habilitados para lecturas optimizadas**: mediante el uso de objetos temporales, puede lograr un procesamiento de consultas más rápido si ubica los archivos temporales generados por PostgreSQL en el almacenamiento NVMe local. Así se reduce el tráfico hacia Elastic Block Storage (EBS) a través de la red. Ofrece una latencia y un rendimiento hasta dos veces mejores para consultas avanzadas que ordenan, unen o fusionan grandes volúmenes de datos que no caben en la capacidad de memoria disponible en una instancia de base de datos. En un clúster optimizado para E/S de Aurora, las lecturas optimizadas utilizan tanto la caché por niveles como los objetos temporales del almacenamiento NVMe. Con la función de caché por niveles habilitada para lecturas optimizadas, Aurora asigna el doble de la memoria de instancia para objetos temporales, aproximadamente el 10 % del almacenamiento para operaciones internas y el almacenamiento restante como caché por niveles. En un clúster estándar de Aurora, las lecturas optimizadas utilizan únicamente objetos temporales. Los clústeres optimizados para E/S de Aurora le permiten cambiar el tamaño del espacio asignado para los objetos temporales habilitados para lecturas optimizados mediante el parámetro dinámico `aurora_temp_space_size` en el nivel de instancia. Esta característica de cambio de tamaño disponible a partir de las siguientes versiones de PostgreSQL: + Versión 16.8 y todas las versiones posteriores + Versión 15.12 y otras 15 versiones posteriores + Versión 14.17 y otras 14 versiones posteriores Con este parámetro, puede redimensionar la capacidad de 2 a 6 veces la memoria de la instancia sin necesidad de reiniciar el motor de base de datos. Cuando expande el espacio de objetos temporales, el cambio surte efecto inmediatamente, independientemente de las cargas de trabajo concurrentes. Sin embargo, al reducir el espacio, el ajuste solo se completa cuando hay suficiente espacio no utilizado en los objetos temporales para adaptarse a la nueva solicitud de tamaño. Tras cambiar el tamaño de los objetos temporales habilitados para lecturas optimizadas, la caché por niveles se ajusta automáticamente para utilizar cualquier espacio disponible. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.optimized.reads.html) **nota** Al cambiar entre clústeres estándar y optimizados para E/S en una clase de instancia de base de datos basada en NVMe, se reinicia inmediatamente el motor de base de datos. En Aurora PostgreSQL, utilice el parámetro `temp_tablespaces` para configurar el espacio de tabla donde se almacenan los objetos temporales. Para comprobar si los objetos temporales están configurados, utilice el siguiente comando: ``` postgres=> show temp_tablespaces; temp_tablespaces --------------------- aurora_temp_tablespace (1 row) ``` `aurora_temp_tablespace` es un espacio de tabla configurado por Aurora que apunta hacia el almacenamiento local de NVMe. No puede modificar este parámetro ni volver al almacenamiento de Amazon EBS. Para comprobar si la caché de lecturas optimizada está activada, utilice el siguiente comando: ``` postgres=> show shared_preload_libraries; shared_preload_libraries -------------------------------------------------------- rdsutils,pg_stat_statements,aurora_optimized_reads_cache ``` ## Uso de lecturas optimizadas de Aurora Al aprovisionar una instancia de base de datos de Aurora PostgreSQL con instancias de base de datos basadas en NVMe, la instancia de base de datos utiliza automáticamente lecturas optimizadas de Aurora. Para activar las lecturas optimizadas de Aurora, realice una de las siguientes acciones: + Para crear un clúster de base de datos de Aurora PostgreSQL, utilice una de las clases de instancia de base de datos basadas en NVMe. Para obtener más información, consulte [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md). + Modifique un clúster de base de datos de Aurora PostgreSQL para utilizar una de las clases de instancia de base de datos basadas en NVMe. Para obtener más información, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md). Las lecturas optimizadas de Aurora están disponibles en todas las Regiones de AWS donde se admite una o más de las clases de instancia de base de datos con almacenamiento SSD NVMe local. Para obtener más información, consulte [Clases de instancia de base de datos de Amazon Aurora](Concepts.DBInstanceClass.md). Para volver a una instancia de Aurora con lecturas no optimizadas, modifique la clase de instancia de base de datos de su instancia de Aurora por una clase de instancia similar sin almacenamiento efímero de NVMe para sus cargas de trabajo de base de datos. Por ejemplo, si la clase de instancia de base de datos actual es db.r6gd.4xlarge, elija db.r6g.4xlarge para volver atrás. Para obtener más información, consulte [Modificación de una instancia de base de datos de Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html). ## Casos de uso de lecturas optimizadas de Aurora **Caché por niveles optimizada y habilitada para las lecturas optimizadas** Estos son algunos casos de uso que pueden beneficiarse de las lecturas optimizadas con caché por niveles: + Aplicaciones de Internet como procesamiento de pagos, facturación, comercio electrónico con estrictos SLA de rendimiento. + Paneles de informes en tiempo real que ejecutan cientos de consultas puntuales para recopilar métricas o datos. + Aplicaciones de IA generativa con la extensión pgvector para buscar vecinos exactos o más cercanos entre millones de incrustaciones vectoriales. **Objetos temporales habilitados para lecturas optimizadas** Estos son algunos casos de uso que pueden beneficiarse de las lecturas optimizadas con objetos temporales: + Consultas analíticas que incluyen expresiones comunes de tabla (CTE), tablas derivadas y operaciones de agrupación. + Réplicas de lectura que gestionan consultas no optimizadas de una aplicación. + Consultas de informes dinámicas o bajo demanda con operaciones complejas, como GROUP BY y ORDER BY, que no siempre pueden utilizar los índices adecuados. + Operaciones `CREATE INDEX` o `REINDEX` de ordenación. + Otras cargas de trabajo que utilizan tablas temporales internas. ## Supervisión de instancias de base de datos que utilizan lecturas optimizadas de Aurora Puede supervisar las consultas que utilizan la caché por niveles habilitada para lecturas optimizadas con el comando EXPLAIN, como se muestra en el siguiente ejemplo: ``` Postgres=> EXPLAIN (ANALYZE, BUFFERS) SELECT c FROM sbtest15 WHERE id=100000000 QUERY PLAN -------------------------------------------------------------------------------------- Index Scan using sbtest15_pkey on sbtest15 (cost=0.57..8.59 rows=1 width=121) (actual time=0.287..0.288 rows=1 loops=1) Index Cond: (id = 100000000) Buffers: shared hit=3 read=2 aurora_orcache_hit=2 I/O Timings: shared/local read=0.264 Planning: Buffers: shared hit=33 read=6 aurora_orcache_hit=6 I/O Timings: shared/local read=0.607 Planning Time: 0.929 ms Execution Time: 0.303 ms (9 rows) Time: 2.028 ms ``` **nota** Los campos `aurora_orcache_hit` y `aurora_storage_read` de la sección `Buffers` del plan explicativo solo se muestran cuando las lecturas optimizadas están activadas y sus valores son superiores a cero. El campo de lectura es el total de los campos `aurora_orcache_hit` y `aurora_storage_read`. Puede supervisar las instancias de base de datos que utilizan lecturas optimizadas de Aurora con las siguientes métricas de CloudWatch: + `AuroraOptimizedReadsCacheHitRatio` + `FreeEphemeralStorage` + `ReadIOPSEphemeralStorage` + `ReadLatencyEphemeralStorage` + `ReadThroughputEphemeralStorage` + `WriteIOPSEphemeralStorage` + `WriteLatencyEphemeralStorage` + `WriteThroughputEphemeralStorage` Estas métricas proporcionan datos sobre el almacén de instancias disponible, las IOPS y el rendimiento. Para obtener más información acerca de estas métricas, consulte [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). También puede utilizar la extensión `pg_proctab` para supervisar el almacenamiento NVMe. ``` postgres=>select * from pg_diskusage(); major | minor | devname | reads_completed | reads_merged | sectors_read | readtime | writes_completed | writes_merged | sectors_written | writetime | current_io | iotime | totaliotime ------+-------+---------------------+-----------------+--------------+--------------+----------+------------------+---------------+-----------------+-----------+------------+---------+------------- | | rdstemp | 23264 | 0 | 191450 | 11670 | 1750892 | 0 | 24540576 | 819350 | 0 | 3847580 | 831020 | | rdsephemeralstorage | 23271 | 0 | 193098 | 2620 | 114961 | 0 | 13845120 | 130770 | 0 | 215010 | 133410 (2 rows) ``` ## Prácticas recomendadas para lecturas optimizadas de Aurora Utilice estas prácticas recomendadas para las lecturas optimizadas de Aurora: + Supervise el espacio de almacenamiento disponible en el almacén de instancias con la métrica de CloudWatch `FreeEphemeralStorage`. Si el almacén de instancias alcanza su límite debido a la carga de trabajo de la instancia de base de datos, ajuste la simultaneidad y las consultas que utilicen demasiados objetos temporales o modifíquelas para utilizar una clase de instancia de base de datos más grande. + Supervise la métrica de CloudWatch para conocer la tasa de aciertos de caché de lecturas optimizadas. Operaciones como VACUUM modifican grandes cantidades de bloques con gran rapidez. Esto puede provocar una caída temporal en la tasa de aciertos. La extensión `pg_prewarm` se puede utilizar para cargar datos en la caché del búfer que permite a Aurora escribir algunos de estos bloques directamente en la caché de lecturas optimizadas. + Puede habilitar la administración de la caché de clúster (CCM) para calentar la caché del búfer y la caché por niveles en un lector de nivel 0, que se utilizará como destino de conmutación por error. Si la CCM está activada, la caché del buffer se escanea periódicamente para escribir páginas que puedan eliminarse en la caché por niveles. Para obtener más información sobre CCM, consulte [Recuperación rápida después de una conmutación por error con la administración de caché del clúster para Aurora PostgreSQL](AuroraPostgreSQL.cluster-cache-mgmt.md). # Optimización de subconsultas correlacionadas en Aurora PostgreSQL Una subconsulta correlacionada hace referencia a las columnas de la tabla desde la consulta externa. Se evalúa una vez por cada fila devuelta por la consulta externa. En el siguiente ejemplo, la subconsulta hace referencia a una columna de la tabla ot. Esta tabla no está incluida en la cláusula FROM de la subconsulta, pero se hace referencia a ella en la cláusula FROM de la consulta externa. Si la tabla ot tiene 1 millón de filas, la subconsulta debe evaluarse 1 millón de veces. ``` SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); ``` **nota** La transformación de subconsultas y la caché de subconsultas están disponibles en Aurora PostgreSQL a partir de la versión 16.8, mientras que Babelfish para Aurora PostgreSQL admite estas características desde la versión 4.2.0. A partir de las versiones 4.6.0 y 5.2.0 de Babelfish para Aurora PostgreSQL, estas características se controlan mediante los siguientes parámetros: babelfishpg\$1tsql.apg\$1enable\$1correlated\$1scalar\$1transform babelfishpg\$1tsql.apg\$1enable\$1subquery\$1cache De forma predeterminada, ambos parámetros están activados. ## Mejora del rendimiento de las consultas de Aurora PostgreSQL mediante la transformación de subconsultas Aurora PostgreSQL puede acelerar las subconsultas correlacionadas transformándolas en uniones externas equivalentes. Esta optimización se aplica a los dos tipos siguientes de subconsultas correlacionadas: + Subconsultas que devuelven un único valor agregado y aparecen en la lista SELECT. ``` SELECT ot.a, ot.b, (SELECT AVG(it.b) FROM it WHERE it.a = ot.a) FROM ot; ``` + Subconsultas que devuelven un único valor agregado y aparecen en una cláusula WHERE. ``` SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); ``` ### Habilitar la transformación en la subconsulta Para habilitar la transformación de subconsultas correlacionadas en uniones externas equivalentes, defina el parámetro `apg_enable_correlated_scalar_transform` en `ON`. El valor predeterminado de este parámetro es `OFF`. Puede modificar el grupo de parámetros de instancia o clúster para establecer los parámetros. Para obtener más información, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). De forma alternativa, puede configurar los ajustes solo para la sesión actual mediante el siguiente comando: ``` SET apg_enable_correlated_scalar_transform TO ON; ``` ### Verificación de transformaciones Utilice el comando EXPLAIN para comprobar si la subconsulta correlacionada se ha transformado en una combinación externa en el plan de consultas. Cuando la transformación esté habilitada, la parte de la subconsulta correlacionada aplicable se transformará en una combinación externa. Por ejemplo: ``` postgres=> CREATE TABLE ot (a INT, b INT); CREATE TABLE postgres=> CREATE TABLE it (a INT, b INT); CREATE TABLE postgres=> SET apg_enable_correlated_scalar_transform TO ON; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); QUERY PLAN -------------------------------------------------------------- Hash Join Hash Cond: (ot.a = apg_scalar_subquery.scalar_output) Join Filter: ((ot.b)::numeric < apg_scalar_subquery.avg) -> Seq Scan on ot -> Hash -> Subquery Scan on apg_scalar_subquery -> HashAggregate Group Key: it.a -> Seq Scan on it ``` La misma consulta no se transforma cuando el parámetro GUC pasa a `OFF`. El plan no tendrá una combinación externa, sino un subplan. ``` postgres=> SET apg_enable_correlated_scalar_transform TO OFF; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); QUERY PLAN ---------------------------------------- Seq Scan on ot Filter: ((b)::numeric < (SubPlan 1)) SubPlan 1 -> Aggregate -> Seq Scan on it Filter: (a = ot.a) ``` ### Limitaciones + La subconsulta debe estar en la lista SELECT o en una de las condiciones de la cláusula WHERE. De lo contrario, no se transformará. + La subconsulta debe devolver una función agregada. Las funciones de agregado definidas por el usuario no se admiten para la transformación. + Una subconsulta cuya expresión de devolución no sea una simple función agregada no se transformará. + La condición correlacionada en las cláusulas WHERE de la subconsulta debe ser una referencia de columna simple. De lo contrario, no se transformará. + La condición correlacionada en las cláusulas WHERE de la subconsulta debe ser un predicado de igualdad simple. + La subconsulta no puede contener una cláusula HAVING o una cláusula GROUP BY. + La cláusula WHERE de la subconsulta puede contener uno o más predicados combinados con AND. **nota** El impacto de la transformación en el rendimiento varía según el esquema, los datos y la carga de trabajo. La ejecución de subconsultas correlacionada con la transformación puede mejorar significativamente el rendimiento a medida que aumenta el número de filas generadas por la consulta externa. Le recomendamos encarecidamente que pruebe esta característica en un entorno que no sea de producción con su esquema, datos y carga de trabajo reales antes de habilitarla en un entorno de producción. ## Uso de la caché de subconsultas para mejorar el rendimiento de las consultas de Aurora PostgreSQL Aurora PostgreSQL admite la caché de subconsultas para almacenar los resultados de las subconsultas correlacionadas. Esta característica omite las ejecuciones repetidas de subconsultas correlacionadas cuando los resultados de las subconsultas ya están en la memoria caché. ### La caché de subconsultas El nodo Memoize de PostgreSQL es la parte clave de la caché de subconsultas. El nodo Memoize mantiene una tabla hash en la caché local para hacer asignaciones desde los valores de los parámetros de entrada a las filas de resultados de las consultas. El límite de memoria de la tabla hash es el producto de work\$1mem y hash\$1mem\$1multiplier. Para obtener más información, consulte [Resource Consumption](https://www.postgresql.org/docs/16/runtime-config-resource.html). Durante la ejecución de la consulta, la caché de subconsultas utiliza la tasa de aciertos de caché (CHR) para estimar si la caché mejora el rendimiento de las consultas y para decidir, en el tiempo de ejecución de la consulta, si se debe seguir utilizando la caché. La CHR es la relación entre el número de visitas a caché y el número total de solicitudes. Por ejemplo, si una subconsulta correlacionada debe ejecutarse 100 veces y 70 de esos resultados de ejecución se pueden recuperar de la memoria caché, la CHR es 0,7. Por cada número apg\$1subquery\$1cache\$1check\$1interval de errores de caché, se evalúan las ventajas de la caché de subconsultas comprobando si la CHR es mayor que apg\$1subquery\$1cache\$1hit\$1rate\$1threshold. De lo contrario, la caché se borrará de la memoria y la ejecución de la consulta volverá a la ejecución original (reejecución de subconsulta sin caché). ### Parámetros que controlan el comportamiento de la caché de subconsultas En la siguiente tabla se muestran los parámetros que controlan el comportamiento de la caché de subconsultas. | Parámetro | Descripción | Valor predeterminado | Permitido | | --- | --- | --- | --- | | apg\$1enable\$1subquery\$1cache | Permite el uso de la memoria caché para subconsultas escalares correlacionadas. | OFF | ON, OFF | | apg\$1subquery\$1cache\$1check\$1interval | Establece la frecuencia, en número de errores de caché, para evaluar la tasa de aciertos de caché de subconsultas. | 500 | 0–2147483647 | | apg\$1subquery\$1cache\$1hit\$1rate\$1threshold | Establece el umbral de la tasa de aciertos de caché de subconsultas. | 0.3 | 0,0-1,0 | **nota** Los valores más altos de `apg_subquery_cache_check_interval` pueden mejorar la precisión de la estimación de los beneficios de la memoria caché según la CHR, pero aumentarán la sobrecarga de la memoria caché, ya que la CHR no se evaluará hasta que la tabla caché tenga un número `apg_subquery_cache_check_interval` de filas. Los valores altos de `apg_subquery_cache_hit_rate_threshold` sugieren el abandono de la caché de subconsultas y la vuelta a la opción original (reejecución de subconsultas sin caché). Puede modificar el grupo de parámetros de instancia o clúster para establecer los parámetros. Para obtener más información, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). De forma alternativa, puede configurar los ajustes solo para la sesión actual mediante el siguiente comando: ``` SET apg_enable_subquery_cache TO ON; ``` ### Activación de la caché de subconsultas en Aurora PostgreSQL Cuando la caché de subconsultas está habilitada, Aurora PostgreSQL aplica la caché para guardar los resultados de las subconsultas. El plan de consultas tendrá entonces un nodo Memoize en SubPlan. Por ejemplo, la siguiente secuencia de comandos muestra el plan de ejecución de consultas estimado de una subconsulta correlacionada simple sin caché de subconsultas. ``` postgres=> SET apg_enable_subquery_cache TO OFF; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ------------------------------------ Seq Scan on ot Filter: (b < (SubPlan 1)) SubPlan 1 -> Seq Scan on it Filter: (a = ot.a) ``` Tras activar `apg_enable_subquery_cache`, el plan de consultas incluirá un nodo Memoize bajo el nodo SubPlan, lo que indica que la subconsulta planea usar la memoria caché. ``` postgres=> SET apg_enable_subquery_cache TO ON; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ------------------------------------ Seq Scan on ot Filter: (b < (SubPlan 1)) SubPlan 1 -> Memoize Cache Key: ot.a Cache Mode: binary -> Seq Scan on it Filter: (a = ot.a) ``` El plan de ejecución de consultas actual contiene más detalles de la caché de subconsultas, incluidos los aciertos y los errores de caché. El siguiente resultado muestra el plan real de ejecución de la consulta del ejemplo anterior tras insertar algunos valores en las tablas. ``` postgres=> EXPLAIN (COSTS FALSE, TIMING FALSE, ANALYZE TRUE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ----------------------------------------------------------------------------- Seq Scan on ot (actual rows=2 loops=1) Filter: (b < (SubPlan 1)) Rows Removed by Filter: 8 SubPlan 1 -> Memoize (actual rows=0 loops=10) Cache Key: ot.a Cache Mode: binary Hits: 4 Misses: 6 Evictions: 0 Overflows: 0 Memory Usage: 1kB -> Seq Scan on it (actual rows=0 loops=6) Filter: (a = ot.a) Rows Removed by Filter: 4 ``` El número total de aciertos de caché es 4 y el número total de errores de caché es 6. Si el número total de aciertos y errores es inferior al número de bucles del nodo Memoize, la evaluación de la CHR no se ha aprobado, y la caché se ha borrado y abandonado en algún momento. A continuación, la ejecución de la subconsulta ha vuelto a la reejecución original sin caché. ### Limitaciones La caché de subconsultas no admite ciertos patrones de subconsultas correlacionadas. Estos tipos de consultas se ejecutarán sin caché, aunque la caché de subconsultas esté activada: + Subconsultas correlacionadas IN/EXISTS/ANY/ALL + Subconsultas correlacionadas que contienen funciones no deterministas. + Subconsultas correlacionadas que hacen referencia a columnas de tablas externas con tipos de datos que no admiten operaciones de hash o igualdad. # Mejora del rendimiento de las consultas mediante la unión adaptativa ## Descripción general La unión adaptativa es una característica de vista previa de Aurora PostgreSQL 17.4 que ayuda a mejorar el rendimiento de las consultas. Esta característica está desactivada de forma predeterminada, pero puede habilitarla mediante los parámetros de configuración global de usuario (GUC). Como se trata de una característica de vista previa, es posible que los valores de los parámetros predeterminados cambien. Cuando está habilitada, la unión adaptativa ayuda a optimizar el rendimiento de las consultas al cambiar dinámicamente de una unión de bucles anidados a una combinación hash en tiempo de ejecución. Este cambio se produce cuando el optimizador de PostgreSQL ha elegido incorrectamente una unión de bucles anidados debido a estimaciones de cardinalidad imprecisas. ## Configuración de unión adaptativa Puede controlar la unión adaptativa mediante estos tres parámetros de GUC: **Parámetros de configuración de unión adaptativa** | Parámetro de GUC | Descripción | Opciones predeterminadas y de configuración | | --- | --- | --- | | apg\$1adaptive\$1join\$1crossover\$1multiplier | Este multiplicador funciona con el punto de cruce de filas para determinar cuándo cambiar de un bucle anidado a una combinación hash. El punto de cruce de filas es donde el optimizador SQL estima que las operaciones de unión de bucle anidado y combinación hash tienen el mismo costo. Un valor multiplicador más alto reduce la probabilidad de que la unión adaptativa cambie a una combinación hash. | Controla si la unión adaptativa está habilitada [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) | | apg\$1adaptive\$1join\$1cost\$1threshold | Este parámetro establece un umbral mínimo de costo de consulta. La unión adaptativa se desactiva automáticamente para las consultas por debajo de este umbral. Esto evita la sobrecarga de rendimiento en consultas sencillas, en las que el costo de planificar una unión adaptativa podría superar los beneficios de cambiar de un bucle anidado a una combinación hash. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) | | apg\$1enable\$1parameterized\$1adaptive\$1join | Este parámetro amplía la funcionalidad de unión adaptativa a las uniones de bucles anidados parametrizadas cuando está habilitado. De forma predeterminada, la unión adaptativa solo funciona con uniones de bucle anidadas sin parametrizar, ya que es más probable que se beneficien del cambio a la combinación hash. Las uniones de bucle anidadas parametrizadas suelen funcionar mejor, lo que hace que el cambio a una combinación hash sea menos crítico. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) Requiere que `apg_adaptive_join_crossover_multiplier` esté habilitado primero | # Uso de caché compartida de planes ## Descripción general Aurora PostgreSQL utiliza un modelo de proceso por usuario en el que cada conexión de cliente crea un proceso de backend dedicado. Cada proceso de backend mantiene su propia caché de plan local para las instrucciones preparadas. Dado que estas cachés no se pueden compartir entre procesos, las aplicaciones que utilizan muchas instrucciones preparadas pueden crear cachés duplicadas en diferentes procesos de backend, lo que provoca un aumento del uso de memoria. Las versiones 17.6 y posteriores, y 16.10 y posteriores, de Aurora PostgreSQL introducen la funcionalidad de caché compartida de planes. Al habilitar esta característica, los procesos de backend pueden compartir planes genéricos, lo que reduce el uso de memoria y mejora el rendimiento al eliminar la generación de planes duplicados. La caché compartida de planes utiliza los siguientes componentes como clave de caché: + Cadena de consulta (incluidos los comentarios) + Parámetros GUC relacionados con el planificador (incluido `search_path`) + ID de usuario + ID de base de datos Los reinicios de la instancia restablecen la caché compartida. ## Parameters La siguiente tabla describe los parámetros que controlan la característica de caché compartida de planes: | Parámetro | Descripción | Valor predeterminado | Permitido | | --- | --- | --- | --- | | apg\$1shared\$1plan\$1cache.enable | Activa o desactiva la caché compartida de planes. | 0 (desactivada) | 0, 1 | | apg\$1shared\$1plan\$1cache.max | El número máximo de entradas de caché. | 200-1000 (dependiente del tamaño de la instancia) | 100–50000 | | apg\$1shared\$1plan\$1cache.min\$1size\$1per\$1entry | El tamaño mínimo de plan que se debe almacenar en la caché compartida. Los planes más pequeños utilizan la caché local para optimizar el rendimiento de OLTP. | 16 KB | 0-32768 (KB) | | apg\$1shared\$1plan\$1cache.max\$1size\$1per\$1entry | El tamaño máximo del plan para la caché compartida. Los planes más grandes solo almacenan información sobre el costo. | 256 KB-4 MB (dependiente del tamaño de la instancia) | 0-32768 (KB) | | apg\$1shared\$1plan\$1cache.idle\$1generic\$1plan\$1release\$1timeout | El tiempo tras el cual las sesiones inactivas liberan los planes genéricos locales. Los valores más bajos ahorran memoria; los valores más altos pueden mejorar el rendimiento. | 10 segundos | 0-2147483647 (ms) | **nota** Puede modificar todos los parámetros sin necesidad de reiniciar. ## Vistas y funciones de monitoreo + `apg_shared_plan_cache()`: muestra información detallada sobre las entradas de caché (accesos, validez, marcas de tiempo). + `apg_shared_plan_cache_stat()`: muestra estadísticas a nivel de instancia (expulsiones, invalidaciones). + `apg_shared_plan_cache_reset()`: elimina todas las entradas en `apg_shared_plan_cache()` y `apg_shared_plan_cache_stat()`. + `apg_shared_plan_cache_remove(cache_key)`: elimina una entrada de `apg_shared_plan_cache()` cuando esta coincide con `cache_key`. ## Limitaciones + Solo funciona con instrucciones preparadas y no almacena en caché instrucciones PL/pgSQL. + No almacena en caché una consulta que contenga tablas temporales o tablas de catálogo. + No almacena en caché una consulta que dependa de RLS (seguridad de nivel de fila). + Cada réplica mantiene su propia caché (no se comparte entre réplicas).