# Administración de planes de ejecución de consultas para Aurora PostgreSQL
La administración de planes de consultas de Aurora PostgreSQL es una función opcional que puede utilizar con su clúster de base de datos de Edición compatible con Amazon Aurora PostgreSQL. Esta característica se empaqueta como la extensión `apg_plan_mgmt` que puede instalar en su clúster de base de datos de Aurora PostgreSQL. La administración de planes de consulta le permite administrar los planes de ejecución de consultas generados por el optimizador para sus aplicaciones SQL. La extensión `apg_plan_mgmt` de AWS se basa en la funcionalidad de procesamiento de consultas nativa del motor de base de datos PostgreSQL.
A continuación, encontrará información sobre las funciones de administración del planes de consultas de Aurora PostgreSQL, cómo configurarlas y cómo utilizarlas con su clúster de base de datos de Aurora PostgreSQL. Antes de empezar, le recomendamos que revise las notas de la versión específica de la extensión `apg_plan_mgmt` disponible para su versión de Aurora PostgreSQL. Para obtener más información sobre Aurora PostgreSQL, consulte [Aurora PostgreSQL apg\$1plan\$1mgmt extension versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) (Versiones de la extensión apg\$1plan\$1mgmt de Aurora PostgreSQL) en las *Notas de la versión de Aurora PostgreSQL*.
**Topics**
+ [Descripción general de la administración de planes de consultas en Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md)
+ [Prácticas recomendadas para la administración de planes de consultas de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.BestPractice.md)
+ [Administración de planes de consultas en Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Start.md)
+ [Captura de planes de ejecución de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md)
+ [Uso de los planes administrados de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md)
+ [Examinación de los planes de consultas de Aurora PostgreSQL en la vista dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md)
+ [Mejora de los planes de consultas en Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.md)
+ [Eliminación de planes de consultas en Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Deleting.md)
+ [Importación y exportación de planes administrados para Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.ExportingImporting.md)
+ [Referencia de parámetros para la administración de planes de consultas de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Parameters.md)
+ [Referencia de funciones para la administración de planes de consultas de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Functions.md)
+ [Referencia de la vista apg\$1plan\$1mgmt.dba\$1plans para la edición compatible con Aurora PostgreSQL](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md)
+ [Funciones avanzadas de la administración de planes de consultas](AuroraPostgreSQL.QPM.Advanced.md)
# Descripción general de la administración de planes de consultas en Aurora PostgreSQL
La administración de planes de consultas de Aurora PostgreSQL se ha diseñada para garantizar la estabilidad del plan independientemente de los cambios en la base de datos que puedan provocar una regresión del plan de consultas La *regresión del plan de consultas* se produce cuando el optimizador elige un plan subóptimo para una sentencia SQL determinada después de cambios en el sistema o la base de datos. Los cambios en estadísticas, restricciones, configuración del entorno, enlaces de parámetros de consultas y actualizaciones del motor de base de datos PostgreSQL pueden provocar una regresión del plan.
Con la gestión del plan de consultas de Aurora PostgreSQL, puede controlar cómo y cuándo cambian los planes de ejecución de las consultas. Entre los beneficios de la administración de planes de consultas en Aurora PostgreSQL se incluyen los siguientes.
+ Obligar al optimizador a elegir a partir de un número limitado de planes buenos y conocidos para mejorar la estabilidad de los planes.
+ Optimizar los planes de manera centralizada y, a continuación, distribuir los mejores planes globalmente.
+ Identificar índices fuera de uso y evaluar el impacto de crear o anular un índice.
+ Detectar automáticamente un nuevo plan de costo mínimo que el optimizador haya descubierto.
+ Probar características de optimizador nuevas con un menor nivel de riesgo, porque puede optar por aprobar únicamente las modificaciones de planes que mejoren el rendimiento.
Puede utilizar las herramientas que proporciona la administración de planes de consultas de forma proactiva para especificar el mejor plan para determinadas consultas. O bien, puede utilizar la administración de planes de consultas para reaccionar ante las circunstancias cambiantes y evitar las regresiones del plan. Para obtener más información, consulte [Prácticas recomendadas para la administración de planes de consultas de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.BestPractice.md).
**Topics**
+ [Instrucciones SQL compatibles](#AuroraPostgreSQL.Optimize.overview.features)
+ [Limitaciones de la administración de planes de consultas](#AuroraPostgreSQL.Optimize.overview.limitations)
+ [Terminología de administración de planes de consultas](#AuroraPostgreSQL.Optimize.Start-terminology)
+ [Versiones de administración de planes de consultas en Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.overview.versions)
+ [Activación de la administración de planes de consultas en Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Enable)
+ [Actualización de la administración de planes de consultas en Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Upgrade)
+ [Desactivación de la administración de planes de consultas en Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Enable.turnoff)
## Instrucciones SQL compatibles
La administración de planes de consultas admite los siguientes tipos de instrucciones SQL.
+ Cualquier instrucción SELECT, INSERT, UPDATE o DELETE, independientemente de su complejidad.
+ Instrucciones preparadas. Para más información, consulte [PREPARE](https://www.postgresql.org/docs/14/sql-prepare.html) en la documentación de PostgreSQL.
+ Instrucciones dinámicas, incluidas las que se ejecutan en modo inmediato. Para obtener más información, consulte [Dynamic SQL](https://www.postgresql.org/docs/current/ecpg-dynamic.html) y [EXECUTE IMMEDIATE](https://www.postgresql.org/docs/current/ecpg-sql-execute-immediate.html) en la documentación de PostgreSQL.
+ Comandos e instrucciones SQL incrustados. Para obtener más información, consulte [Embedded SQL Commands](https://www.postgresql.org/docs/current/ecpg-sql-commands.html) en la documentación de PostgreSQL.
+ Instrucciones dentro de funciones denominadas. Para obtener más información, consulte [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) en la documentación de PostgreSQL.
+ Instrucciones que contienen tablas temporales.
+ Instrucciones dentro de procedimientos y bloques DO.
Puede utilizar la administración de planes de consultas con `EXPLAIN` en modo manual para capturar un plan sin ejecutarlo en realidad. Para obtener más información, consulte [Análisis del plan elegido por el optimizador](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans). Para obtener más información sobre los modos de administración del plan de consultas (manual o automático), consulte [Captura de planes de ejecución de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
La administración de planes de consulta de Aurora PostgreSQL es compatible con todas las características del lenguaje PostgreSQL, incluidas las tablas particionadas, la herencia, la seguridad a nivel de fila y las expresiones comunes de tabla (CTE) recursivas. Para obtener más información sobre estas funciones del lenguaje PostgreSQL, consulte [Table Partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html), [Row Security Policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) y [WITH Queries (Common Table Expressions)](https://www.postgresql.org/docs/current/queries-with.html) y otros temas en la documentación de PostgreSQL.
Para obtener información sobre las diferentes versiones de la característica de administración de planes de consultas de Aurora PostgreSQL, consulte las [versiones de la extensión apg\$1plan\$1mgmt de Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) en las *notas de la versión de Aurora PostgreSQL*.
## Limitaciones de la administración de planes de consultas
La versión actual de la administración de planes de consultas de Aurora PostgreSQL tiene las siguientes limitaciones.
+ **Los planes no se capturan para las instrucciones que hacen referencia a las relaciones del sistema:** las instrucciones que hacen referencia a las relaciones del sistema como, por ejemplo `pg_class`, no se capturan. Esto es por diseño, para evitar que se capture una gran cantidad de planes generados por el sistema que se utilizan internamente. Esto también se aplica a las tablas del sistema dentro de las vistas.
+ **Es posible que se necesite una clase de instancia de base de datos más grande para el clúster de base de datos de Aurora PostgreSQL**: según la carga de trabajo, la administración de planes de consultas podría necesitar una clase de instancia de base de datos que tenga más de 2 vCPU El número de `max_worker_processes` está limitado por el tamaño de la clase de instancia de base de datos. Es posible que el número de `max_worker_processes` que proporciona una clase de instancia de base de datos de 2 vCPU (db.t3.medium, por ejemplo) no sea suficiente para una carga de trabajo determinada. Le recomendamos que elija una clase de instancia de base de datos con más de 2 vCPU para su clúster de base de datos de Aurora PostgreSQL si utiliza la administración de planes de consultas.
Cuando la clase de instancia de la base de datos no puede soportar la carga de trabajo, la administración de planes de consulta emite un mensaje de error como el siguiente.
```
WARNING: could not register plan insert background process
HINT: You may need to increase max_worker_processes.
```
En este caso, debe ampliar el clúster de base de datos de Aurora PostgreSQL a un tamaño de clase de instancia de base de datos con más memoria. Para obtener más información, consulte [Motores de base de datos compatibles para clases de instancia de base de datos](Concepts.DBInstanceClass.SupportAurora.md).
+ **Los planes que ya estén almacenados en las sesiones no se ven afectados**: la administración del plan de consultas proporciona una forma de influir en los planes de consultas sin cambiar el código de la aplicación. Sin embargo, si un plan genérico ya está almacenado en una sesión existente y desea cambiar su plan de consultas, primero debe configurar `plan_cache_mode` en `force_custom_plan` en el grupo de parámetros del clúster de base de datos.
+ `queryid` en `apg_plan_mgmt.dba_plans` y `pg_stat_statements` pueden diferir cuando:
+ Los objetos se eliminan y se vuelven a crear después de guardarlos en apg\$1plan\$1mgmt.dba\$1plans.
+ La tabla `apg_plan_mgmt.plans` se importa de otro clúster.
Para obtener información sobre las diferentes versiones de la característica de administración de planes de consultas de Aurora PostgreSQL, consulte las [versiones de la extensión apg\$1plan\$1mgmt de Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) en las *notas de la versión de Aurora PostgreSQL*.
## Terminología de administración de planes de consultas
Los siguientes términos se utilizan en este tema:
**instrucción administrada**
Una instrucción SQL capturada por el optimizador mediante la administración del plan de consultas. Una instrucción administrada tiene uno o más planes de ejecución de consultas almacenados en la vista `apg_plan_mgmt.dba_plans`.
**línea base del plan**
El conjunto de planes aprobados para una instrucción administrada determinada. Es decir, todos los planes de la instrucción administrada que tienen «Aprobado» en su columna `status` de la vista de `dba_plan`.
**historial del plan**
El conjunto de todos los planes capturados para una instrucción administrada determinada. El historial del plan contiene todos los planes capturados para la instrucción, independientemente de su estado.
**regresión del plan de consulta**
El caso en el que el optimizador elige un plan menos óptimo que antes de un cambio determinado en el entorno de la base de datos, como una nueva versión de PostgreSQL o cambios en las estadísticas.
## Versiones de administración de planes de consultas en Aurora PostgreSQL
La administración de planes de consultas es compatible con todas las versiones de Aurora PostgreSQL disponibles actualmente. Para obtener información detallada sobre la versión, consulte la lista de [actualizaciones de Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) en las *notas de la versión de Aurora PostgreSQL*.
La funcionalidad de administración de planes de consultas se agrega al clúster de base de datos de Aurora PostgreSQL al instalar la extensión `apg_plan_mgmt`. Las distintas versiones de Aurora PostgreSQL admiten distintas versiones de la extensión `apg_plan_mgmt`. Le recomendamos que actualice la extensión de administración de planes de consultas a la versión más reciente de su versión de Aurora PostgreSQL.
**nota**
Para ver las notas de la versión de cada una de las versiones de la extensión `apg_plan_mgmt`, consulte las [versiones de extensión apg\$1plan\$1mgmt de Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) en las *notas de la versión de Aurora PostgreSQL*.
Puede identificar la versión que se ejecuta en su clúster conectándose a una instancia mediante `psql` y utilizando el metacomando\$1 dx para enumerar las extensiones, tal como se muestra a continuación.
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------------+---------+---------------+-------------------------------------------------------------------
apg_plan_mgmt | 1.0 | apg_plan_mgmt | Amazon Aurora with PostgreSQL compatibility Query Plan Management
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(2 rows)
```
El resultado muestra que este clúster utiliza la versión 1.0 de la extensión. Solo hay ciertas versiones de `apg_plan_mgmt` disponibles para una versión determinada de Aurora PostgreSQL. En algunos casos, es posible que necesite actualizar el clúster de base de datos de Aurora PostgreSQL a una nueva versión secundaria o aplicar un parche para poder actualizar a la versión más reciente de la administración del plan de consultas. La versión 1.0 de `apg_plan_mgmt`que se muestra en el resultado proviene de un clúster de base de datos de Aurora PostgreSQL versión 10.17, que no tiene una versión más reciente de `apg_plan_mgmt` disponible. En este caso, el clúster de base de datos de Aurora PostgreSQL debe actualizarse a una versión más reciente de PostgreSQL.
Para obtener más información sobre la actualización de su clúster de bases de datos Aurora PostgreSQL a una nueva versión de PostgreSQL, consulte [Actualizaciones del motor de base de datos de Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md).
Para obtener información sobre cómo actualizar la extensión `apg_plan_mgmt`, consulte [Actualización de la administración de planes de consultas en Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Upgrade).
## Activación de la administración de planes de consultas en Aurora PostgreSQL
La configuración de la administración de planes de consultas para el clúster de base de datos de Aurora PostgreSQL implica instalar una extensión y cambiar varios parámetros del clúster de base de datos. Necesita permisos de `rds_superuser` para instalar la extensión `apg_plan_mgmt` y activar la función del clúster de base de datos de Aurora PostgreSQL.
Al instalar la extensión, se crea un nuevo rol, `apg_plan_mgmt`. Esta función permite a los usuarios de bases de datos ver, administrar y mantener planes de consultas. Como administrador con privilegios `rds_superuser`, asegúrese de conceder el rol de `apg_plan_mgmt` a los usuarios de la base de datos según sea necesario.
Sólo los usuarios con el rol `rds_superuser` pueden completar el procedimiento siguiente. El `rds_superuser` es necesario para crear la extensión `apg_plan_mgmt` y su `apg_plan_mgmt` función. Se debe conceder a los usuarios el rol `apg_plan_mgmt` para administrar la extensión `apg_plan_mgmt`.
**Para activar la administración de planes de consulta para su clúster de bases de datos Aurora PostgreSQL**
Los siguientes pasos activan la administración de planes de consultas para todas las instrucciones SQL que se envían al clúster de base de datos de Aurora PostgreSQL. Esto se conoce como modo *automático*. Para obtener más información sobre la diferencia entre modos, consulte [Captura de planes de ejecución de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Cree un grupo de parámetros de clúster de base de datos personalizado para su clúster de base de datos de Aurora PostgreSQL. Debe cambiar ciertos parámetros para activar la administración de planes de consultas y establecer su comportamiento. Para obtener más información, consulte [Creación de un grupo de parámetros de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.Creating.md).
1. Abra el grupo de parámetros de clúster de base de datos personalizado y establezca el parámetro `rds.enable_plan_management` en `1`, como se muestra en la siguiente imagen.
![\[Imagen del grupo de parámetros de clúster de base de datos.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/aurora-qpm-custom-db-cluster-param-change-1.png)
Para obtener más información, consulte [Modificación de los parámetros en un grupo de parámetros de clúster de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Cree un grupo de parámetros de base de datos personalizado que pueda usar para establecer los parámetros del plan de consultas a nivel de instancia. Para obtener más información, consulte [Creación de un grupo de parámetros de clúster de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md).
1. Modifique la instancia del escritor del clúster de base de datos de Aurora PostgreSQL para que utilice el grupo de parámetros de base de datos personalizado Para obtener más información, consulte [Modificación de una instancia de base de datos en un clúster de base de datos](Aurora.Modifying.md#Aurora.Modifying.Instance).
1. Modifique el clúster de base de datos de Aurora PostgreSQL para que utilice el grupo de parámetros del clúster de base de datos personalizado Para obtener más información, consulte [Modificación del clúster de base de datos con la consola, CLI y API](Aurora.Modifying.md#Aurora.Modifying.Cluster).
1. Reinicie la instancia de base de datos para habilitar la configuración del grupo de parámetros personalizado.
1. Conecte al punto de conexión de la instancia de base de datos de Aurora PostgreSQL mediante `psql` o `pgAdmin`. En el siguiente ejemplo, se usa la cuenta de `postgres` predeterminada del rol de `rds_superuser`.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=my-db
```
1. Cree la extensión `apg_plan_mgmt` para su instancia de base de datos, como se muestra a continuación.
```
labdb=> CREATE EXTENSION apg_plan_mgmt;
CREATE EXTENSION
```
**sugerencia**
Instale la extensión `apg_plan_mgmt` en la base de datos de plantillas de la aplicación. La base de datos de plantillas predeterminada se denomina `template1`. Para obtener más información, consulte [Template Databases](https://www.postgresql.org/docs/current/manage-ag-templatedbs.html) en la documentación de PostgreSQL.
1. Cambie el parámetro `apg_plan_mgmt.capture_plan_baselines` por `automatic`. Esta configuración hace que el optimizador genere planes para cada instrucción SQL que esté planificada o que se ejecute dos o más veces.
**nota**
La administración de planes de consultas también tiene un modo *manual* que puede utilizar para instrucciones SQL específicas. Para obtener más información, consulte [Captura de planes de ejecución de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
1. Cambie el valor del parámetro `apg_plan_mgmt.use_plan_baselines` a «on». Este parámetro hace que el optimizador elija un plan para la instrucción a partir de la línea base del plan. Para obtener más información, consulte [Uso de los planes administrados de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md).
**nota**
Puede modificar el valor de cualquiera de estos parámetros dinámicos de la sesión sin necesidad de reiniciar la instancia.
Cuando la configuración de administración de planes de consultas esté completa, asegúrese de conceder el rol de `apg_plan_mgmt` a todos los usuarios de la base de datos que necesiten ver, administrar o mantener los planes de consultas.
## Actualización de la administración de planes de consultas en Aurora PostgreSQL
Le recomendamos que actualice la extensión de administración de planes de consultas a la versión más reciente de su versión de Aurora PostgreSQL.
1. Conecte a la instancia de escritor de su clúster de base de datos de Aurora PostgreSQL como un usuario que tiene privilegios de `rds_superuser`. Si mantuvo el nombre predeterminado al configurar la instancia, conéctese como `postgres`. En este ejemplo se muestra cómo utilizar `psql`, pero también puede usar pgAdmin si lo prefiere.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Ejecute la siguiente consulta para actualizar la extensión.
```
ALTER EXTENSION apg_plan_mgmt UPDATE TO '2.1';
```
1. Use la función [apg\$1plan\$1mgmt.validate\$1plans](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.validate_plans) para actualizar los hashes de todos los planes. El optimizador valida todos los planes aprobados, no aprobados y rechazados para garantizar que sigan siendo planes viables para la nueva versión de la extensión.
```
SELECT apg_plan_mgmt.validate_plans('update_plan_hash');
```
Para obtener más información sobre el uso de esta función, consulte [Validación de planes](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
1. Utilice la función [apg\$1plan\$1mgmt.reload](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.reload) para actualizar cualquier plan de la memoria compartida con los planes validados de la vista dba\$1plans.
```
SELECT apg_plan_mgmt.reload();
```
Para obtener más información sobre todas las funciones disponibles para la administración del plan de consultas, consulte [Referencia de funciones para la administración de planes de consultas de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Functions.md).
## Desactivación de la administración de planes de consultas en Aurora PostgreSQL
Puede deshabilitar la administración de planes de consultas en cualquier momento al desactivar `apg_plan_mgmt.use_plan_baselines` y `apg_plan_mgmt.capture_plan_baselines`.
```
labdb=> SET apg_plan_mgmt.use_plan_baselines = off;
labdb=> SET apg_plan_mgmt.capture_plan_baselines = off;
```
# Prácticas recomendadas para la administración de planes de consultas de Aurora PostgreSQL
La administración de planes de consultas le permite controlar cuándo y cómo cambian los planes de ejecución de consultas. Como DBA, sus principales objetivos al utilizar QPM incluyen la prevención de regresiones cuando se producen cambios en la base de datos y controlar si permitir que el optimizador utilice un nuevo plan. A continuación, encontrará algunas prácticas recomendadas para utilizar la administración de planes de consultas. Los enfoques de administración de planes proactivos y reactivos difieren en el cómo y el cuándo se aprueban los nuevos planes para su uso.
**Contents**
+ [Administración de planes proactiva para evitar la regresión del rendimiento](#AuroraPostgreSQL.Optimize.BestPractice.Proactive)
+ [Garantizar la estabilidad del plan después de una actualización a una versión principal](#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade)
+ [Administración de planes reactiva para detectar y reparar regresiones del rendimiento](#AuroraPostgreSQL.Optimize.BestPractice.Reactive)
## Administración de planes proactiva para evitar la regresión del rendimiento
Para evitar que se produzcan regresiones en el rendimiento del plan, *desarrolle* las bases de referencia del plan mediante la ejecución de un procedimiento que compare el rendimiento de los planes recién descubiertos con el rendimiento de las bases de referencia existentes de los planes aprobados y, a continuación, apruebe automáticamente el conjunto de planes más rápido como la nueva base de referencia. De esta manera, la base de referencia de los planes mejora con el tiempo a medida que se detectan planes más rápidamente.
1. En un entorno de desarrollo, identifique las instrucciones SQL que causen un mayor impacto en el rendimiento del sistema. Después, capture los planes para estas instrucciones según se describen en [Captura manual de planes para instrucciones SQL específicas](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Manual) y [Captura de planes automática](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Exporte los planes capturados desde el entorno de desarrollo e impórtelos al entorno de producción. Para obtener más información, consulte [Importación y exportación de planes administrados para Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.ExportingImporting.md).
1. En producción, ejecute su aplicación y fuerce el uso de planes administrados aprobados. Para obtener más información, consulte [Uso de los planes administrados de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md). Cuando se ejecute la aplicación, añada nuevos planes también a medida que el optimizador los descubra. Para obtener más información, consulte [Captura de planes automática](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Analice los planes no aprobados y apruebe los que muestren un buen rendimiento. Para obtener más información, consulte [Evaluación del rendimiento de los planes](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
1. Mientras la aplicación continúa ejecutándose, el optimizador empezará a utilizar los nuevos planes, según resulte conveniente.
### Garantizar la estabilidad del plan después de una actualización a una versión principal
Cada versión principal de PostgreSQL incluye mejoras y cambios en el optimizador de consultas que están diseñados para mejorar el rendimiento. Sin embargo, los planes de ejecución de consultas generados por el optimizador en versiones anteriores pueden provocar regresiones en el rendimiento en las versiones actualizadas más recientes. Puede utilizar el administrador de planes de consultas para resolver estos problemas de rendimiento y garantizar la estabilidad del plan tras una actualización de la versión principal.
El optimizador siempre utiliza un plan aprobado con el coste mínimo, incluso si hay más de un plan aprobado para la misma instrucción. Tras una actualización, es posible que el optimizador descubra nuevos planes, pero se guardarán como Planes no aprobados. Estos planes solo se ejecutan si se aprueban mediante el estilo reactivo de gestión de planes con el parámetro unapproved\$1plan\$1execution\$1threshold. Para maximizar la estabilidad del plan, puede utilizar el estilo proactivo de gestión de planes con el parámetro evolve\$1plan\$1baselines. De este modo, se compara el rendimiento de los nuevos planes con el de los antiguos y se aprueban o rechazan aquellos que sean al menos un 10 % más rápidos que el siguiente mejor plan.
Después de la actualización, puede utilizar la función `evolve_plan_baselines` para comparar el rendimiento del plan antes y después de la actualización utilizando los enlaces de parámetros de consultas. En los siguientes pasos, se supone que ha estado utilizando planes administrados aprobados en su entorno de producción, como se detalla en [Uso de los planes administrados de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md).
1. Antes de actualizar, ejecute la aplicación con el administrador de planes de consultas en ejecución. Mientras se ejecuta la aplicación, añada nuevos planes a medida que el optimizador los detecta. Para obtener más información, consulte [Captura de planes automática](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Evalúe el rendimiento de cada plan. Para obtener más información, consulte [Evaluación del rendimiento de los planes](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
1. Después de actualizar, analice de nuevo los planes aprobados utilizando la función `evolve_plan_baselines`. Compare el rendimiento antes y después de utilizar los enlaces de parámetros de consultas. Si el nuevo plan es rápido, puede añadirlo a los planes aprobados. Si es más rápido que otro plan para los mismos enlaces de parámetros, puede marcar el plan más lento como rechazado.
Para obtener más información, consulte [Aprobar planes mejores](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance.Approving). Para obtener información de referencia acerca de esta función, consulte [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines).
Para obtener más información, consulte [Ensuring consistent performance after major version upgrades with Amazon Aurora PostgreSQL-Compatible Edition Query Plan Management](https://aws.amazon.com/blogs/database/ensuring-consistent-performance-after-major-version-upgrades-with-amazon-aurora-postgresql-query-plan-management/).
**nota**
Cuando actualice una versión principal mediante la replicación lógica o AWS DMS, asegúrese de replicar el esquema de `apg_plan_mgmt` para garantizar que los planes existentes se copien en la instancia actualizada. Para obtener más información sobre la replicación lógica, consulte [Uso de la replicación lógica para realizar una actualización de la versión principal para Aurora PostgreSQL](AuroraPostgreSQL.MajorVersionUpgrade.md).
## Administración de planes reactiva para detectar y reparar regresiones del rendimiento
Al monitorizar su aplicación a medida que se ejecuta, puede detectar los planes que causan regresiones del rendimiento. Cuando detecte regresiones, puede rechazar manualmente o reparar los planes defectuosos con estos pasos:
1. Mientras se ejecute su aplicación, fuerce el uso de planes administrados y añada automáticamente los planes recién descubiertos como no aprobados. Para obtener más información, consulte [Uso de los planes administrados de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md) y [Captura de planes automática](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Monitorización de su aplicación en ejecución para detectar regresiones de rendimiento.
1. Cuando descubra una regresión del plan, configure el estado del plan en `rejected`. La próxima vez que el optimizador ejecute la instrucción SQL, ignora automáticamente el plan rechazado y emplea un plan aprobado diferente en su lugar. Para obtener más información, consulte [Rechazar o desactivar planes más lentos](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance.Rejecting).
En algunos casos, puede que prefiera reparar un plan defectuoso en lugar de rechazarlo, deshabilitarlo o eliminarlo. Utilice la extensión `pg_hint_plan` para experimentar con la mejora de un plan. Con `pg_hint_plan`, puede utilizar comentarios especiales para decirle al optimizador que anule cómo crea un plan habitualmente. Para obtener más información, consulte [Corrección de planes mediante pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan).
# Administración de planes de consultas en Aurora PostgreSQL
Con la administración de planes de consultas activada para el clúster de base de datos de Aurora PostgreSQL, el optimizador genera y almacena los planes de ejecución de consultas para cualquier sentencia SQL que procese más de una vez. El optimizador siempre establece el estado del primer plan generado de una instrucción administrada en `Approved` y lo almacena en la vista `dba_plans`.
Un conjunto de planes aprobados para una instrucción administrada se denomina *base de referencia del plan*. A medida que la aplicación se ejecuta, puede que el optimizador encuentre planes adicionales para las instrucciones administradas. El optimizador establece el estado de los planes adicionales capturados en `Unapproved`.
Posteriormente, podrá decidir si los planes `Unapproved` rinden apropiadamente y cambiarlos a `Approved`, `Rejected` o `Preferred`. Para ello, utilice la función `apg_plan_mgmt.evolve_plan_baselines` o la función `apg_plan_mgmt.set_plan_status`.
Cuando el optimizador genera un plan para una sentencia SQL, la administración de planes de consultas guarda el plan en la tabla `apg_plan_mgmt.plans`. Los usuarios de la base de datos a los que se les ha otorgado el rol de `apg_plan_mgmt`pueden ver los detalles del plan consultando la vista `apg_plan_mgmt.dba_plans`. Por ejemplo, la siguiente consulta muestra detalles de los planes que se encuentran actualmente en la vista para un clúster de base de datos de Aurora PostgreSQL que no es de producción.
+ `sql_hash`: identificador de la sentencia SQL que es el valor de hash del texto normalizado de la sentencia SQL.
+ `plan_hash`: identificador único del plan que es una combinación del `sql_hash` y un hash del plan.
+ `status`: estado del plan. El optimizador puede ejecutar un plan aprobado.
+ `enabled`: indica si el plan está listo para usarse (verdadero) o no (falso).
+ `plan_outline`: representación del plan que se utiliza para recrear el plan de ejecución real. Los operadores de la estructura de árbol se asignan a los operadores de la salida EXPLAIN.
La vista `apg_plan_mgmt.dba_plans` tiene muchas más columnas que contienen todos los detalles del plan, por ejemplo, cuándo se utilizó el plan por última vez. Para ver todos los detalles, consulte [Referencia de la vista apg\$1plan\$1mgmt.dba\$1plans para la edición compatible con Aurora PostgreSQL](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md).
## Normalización y el hash SQL
En la vista `apg_plan_mgmt.dba_plans`, puede identificar una instrucción administrada por su valor hash SQL. El hash SQL se calcula sobre una representación normalizada de la instrucción SQL que elimina algunas diferencias, como los valores literales.
El proceso de *normalización* de cada instrucción SQL conserva el espacio y las mayúsculas, de modo que puede seguir leyendo y entendiendo la esencia de la instrucción SQL. La normalización elimina o reemplaza los siguientes elementos.
+ Comentarios del bloque principal
+ La palabra clave EXPLAIN y las opciones EXPLAIN y EXPLAIN ANALYZE
+ Espacios finales
+ Todos los literales
Por ejemplo, tomemos la siguiente instrucción.
```
/*Leading comment*/ EXPLAIN SELECT /* Query 1 */ * FROM t WHERE x > 7 AND y = 1;
```
La administración de planes de consultas estandariza esta instrucción del siguiente modo:
```
SELECT /* Query 1 */ * FROM t WHERE x > CONST AND y = CONST;
```
La normalización permite utilizar el mismo hash SQL para instrucciones SQL similares que pueden diferir únicamente en sus valores literales o de parámetro. En otras palabras, pueden existir varios planes para el mismo hash SQL y un plan diferente que resulte óptimo según diferentes condiciones.
**nota**
Una sola instrucción SQL que se usa con diferentes esquemas tiene diferentes planes porque está vinculada al esquema específico en tiempo de ejecución. El planificador utiliza las estadísticas de enlace de esquemas para elegir el plan óptimo.
Para obtener más información acerca de cómo el optimizador elige un plan, consulte [Uso de los planes administrados de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md). En esa sección, puede aprender a usar `EXPLAIN` y `EXPLAIN ANALYZE` para previsualizar un plan antes de usarlo realmente. Para obtener más información, consulte [Análisis del plan elegido por el optimizador](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans). Para obtener una imagen que describa el proceso de elección de un plan, consulte [Cómo elige el optimizador qué plan ejecutar.](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans).
# Captura de planes de ejecución de Aurora PostgreSQL
La administración de planes de consultas de Aurora PostgreSQL ofrece dos modos diferentes para capturar los planes de ejecución de consultas, automático o manual. Para elegir el modo, defina el valor de `apg_plan_mgmt.capture_plans_baselines` en `automatic` o en `manual`. Puede capturar planes de ejecución para instrucciones SQL específicas mediante una captura del plan manual. También puede capturar todos los planes (o los más lentos) que se pongan en marcha dos o más veces mientras se ejecuta su aplicación utilizando la captura de planes automática.
Al capturar planes, el optimizador establece el estado del primer plan capturado de una instrucción administrada en `approved`. El optimizador establece el estado de cualquier plan adicional capturado para una instrucción administrada en `unapproved`. Sin embargo, puede guardarse ocasionalmente más de un plan con el estado `approved`. Esto puede ocurrir cuando se crean varios planes para una instrucción en paralelo, y antes de que se confirme el primer plan para la instrucción.
Para controlar el número máximo de planes que se pueden capturar y almacenar en la vista `dba_plans`, establezca el parámetro `apg_plan_mgmt.max_plans` en su grupo de parámetros en el nivel de la instancia de la base de datos. Un cambio en el parámetro `apg_plan_mgmt.max_plans` requiere un reinicio de la instancia de base de datos para que el nuevo valor tenga efecto. Para obtener más información, consulte el parámetro [apg\$1plan\$1mgmt.max\$1plans](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.max_plans).
## Captura manual de planes para instrucciones SQL específicas
Si tiene un conjunto conocido de instrucciones SQL para administrar, ponga las instrucciones en un archivo de script SQL y capture manualmente los planes. A continuación se muestra un ejemplo psql de cómo capturar planes de consulta manualmente para un conjunto de instrucciones SQL.
```
psql> SET apg_plan_mgmt.capture_plan_baselines = manual;
psql> \i my-statements.sql
psql> SET apg_plan_mgmt.capture_plan_baselines = off;
```
Tras capturar un plan para cada instrucción SQL, el optimizador añade una nueva fila a la vista `apg_plan_mgmt.dba_plans`.
Recomendamos que utilice instrucciones EXPLAIN o EXPLAIN EXECUTE en el archivo de script de SQL. Asegúrese de que incluye suficientes variaciones en los valores de parámetros para capturar todos los planes de interés.
Si conoce un plan mejor que el plan de costo mínimo del optimizador, puede que sea capaz de forzar al optimizador a que use el plan mejor. Para ello, especifique una o más sugerencias del optimizador. Para obtener más información, consulte [Corrección de planes mediante pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). Para comparar el rendimiento de los planes `unapproved` y `approved` y aprobarlos, rechazarlos o eliminarlos, consulte [Evaluación del rendimiento de los planes](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
## Captura de planes automática
Utilice la captura de planes automática para situaciones como la siguiente:
+ No sabe las instrucciones SQL específicas que quiere administrar.
+ Tiene cientos o miles de instrucciones SQL que administrar.
+ Su aplicación usa una API de cliente. Por ejemplo, JDBC utiliza instrucciones preparadas sin nombre o instrucciones en modo masivo que no se pueden expresar en psql.
**Para capturar planes automáticamente**
1. Active la captura de planes automática configurando `apg_plan_mgmt.capture_plan_baselines` como `automatic` en el grupo de parámetros para la instancia de la base de datos. Para obtener más información, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
1. A medida que se ejecuta la aplicación, el optimizador captura los planes para cada instrucción SQL que se ejecute al menos dos veces.
A medida que se ejecuta la aplicación con los ajustes de parámetro del administrador de planes de consulta predeterminados, el optimizador captura los planes para cada instrucción SQL que se ejecute al menos dos veces. La captura de todos los planes con los valores predeterminados tiene una sobrecarga de tiempo de ejecución muy pequeña y puede habilitarse en producción.
**Para desactivar la captura de planes automática, realice el siguiente parámetro:**
+ En el parámetro `apg_plan_mgmt.capture_plan_baselines`, establezca el valor `off` desde el grupo de parámetros de base de datos.
Para medir el rendimiento de los planes sin aprobar y aprobar, rechazar o eliminar dichos planes, consulte [Evaluación del rendimiento de los planes](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
# Uso de los planes administrados de Aurora PostgreSQL
Para que el optimizador use los planes capturados para sus instrucciones administradas, establezca el parámetro `apg_plan_mgmt.use_plan_baselines` en `true`. A continuación figura el ejemplo de una instancia local.
```
SET apg_plan_mgmt.use_plan_baselines = true;
```
Mientras se ejecuta la aplicación, esta configuración hace que el optimizador utilice el plan de costo mínimo, preferido o aprobado que sea válido y esté habilitado para cada instrucción administrada.
## Análisis del plan elegido por el optimizador
Cuando el parámetro `apg_plan_mgmt.use_plan_baselines` está establecido en `true`, puede utilizar instrucciones SQL EXPLAIN ANALYZE para hacer que el optimizador muestre el plan que usaría si fuera a ejecutar la consulta. A continuación se muestra un ejemplo.
```
EXPLAIN ANALYZE EXECUTE rangeQuery (1,10000);
```
```
QUERY PLAN
--------------------------------------------------------------------------
Aggregate (cost=393.29..393.30 rows=1 width=8) (actual time=7.251..7.251 rows=1 loops=1)
-> Index Only Scan using t1_pkey on t1 t (cost=0.29..368.29 rows=10000 width=0) (actual time=0.061..4.859 rows=10000 loops=1)
Index Cond: ((id >= 1) AND (id <= 10000))
Heap Fetches: 10000
Planning time: 1.408 ms
Execution time: 7.291 ms
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1984047223, Plan Hash: 512153379
```
El resultado muestra el plan aprobado a partir de la línea de base que se ejecutaría. Sin embargo, el resultado también muestra que ha encontrado un plan con un costo menor. En ese caso, capture este plan de costo mínimo activando la captura de planes automática, como se describe en [Captura de planes automática](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
El optimizador siempre captura los nuevos planes como `Unapproved`. Utilice la función `apg_plan_mgmt.evolve_plan_baselines` para comparar planes y cambiarlos a aprobado, rechazado o deshabilitado. Para obtener más información, consulte [Evaluación del rendimiento de los planes](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
## Cómo elige el optimizador qué plan ejecutar.
El costo de un plan de ejecución es un cálculo que realiza el optimizador para comparar planes distintos. Al calcular el costo de un plan, el optimizador incluye factores tales como las operaciones de CPU y E/S requeridas por ese plan. Para obtener más información acerca de las estimaciones de costos del planificador de consultas de PostgreSQL, consulte el tema sobre [planificación de consultas](https://www.postgresql.org/docs/current/runtime-config-query.html) en la documentación de PostgreSQL.
En la siguiente imagen se muestra cómo se elige un plan para una instrucción SQL determinada cuando la administración de planes de consultas está activa y cuándo no.
![\[Flujo de trabajo de la administración de planes de consultas en Aurora PostgreSQL\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/aurora-query-plan-mgmt_processing-flow.png)
El flujo es el siguiente:
1. El optimizador genera un plan de costo mínimo para la instrucción SQL.
1. Si la administración de planes de consultas no está activa, el plan del optimizador se ejecuta inmediatamente (A. Run Optimizer's plan [Ejecutar el plan del optimizador]). La administración de planes de consultas está inactiva cuando los parámetros `apg_plan_mgmt.capture_plan_baselines` y `apg_plan_mgmt.use_plan_baselines` tienen su configuración predeterminada (“off” y “false”, respectivamente).
De lo contrario, la administración de planes de consultas estará activa. En este caso, la instrucción SQL y el plan del optimizador se evalúan más a fondo antes de elegir un plan.
**sugerencia**
Los usuarios de bases de datos con el rol `apg_plan_mgmt` pueden comparar planes de forma proactiva, cambiar el estado de los planes y forzar el uso de planes específicos según sea necesario. Para obtener más información, consulte [Mejora de los planes de consultas en Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.md).
1. Es posible que la instrucción SQL ya tenga planes almacenados previamente por la administración de planes de consultas. Los planes se almacenan en `apg_plan_mgmt.dba_plans`, junto con información sobre las instrucciones SQL que se usaron para crearlas. La información sobre un plan incluye su estado. El estado de un plan puede determinar si se usa o no, de la siguiente manera.
1. Si el plan no está entre los planes almacenados para la instrucción SQL, significa que es la primera vez que el optimizador genera este plan en particular para la instrucción SQL dada. El plan se envía a Capture Plan Processing (Procesamiento del plan de captura) (4).
1. Si el plan se encuentra entre los planes almacenados y su estado es Aprobado o Preferido, se ejecuta el plan (A. Ejecutar el plan del optimizador).
Si el plan se encuentra entre los planes almacenados pero no está Aprobado ni es Preferido, el plan se envía a Procesamiento del plan de captura (4).
1. Cuando se captura un plan por primera vez para una instrucción SQL determinada, el estado del plan siempre se establece en Aprobado (P1). Si el optimizador genera posteriormente el mismo plan para la misma instrucción SQL, el estado de ese plan cambia a No aprobado (P1\$1n).
Con el plan capturado y su estado actualizado, la evaluación continúa en el siguiente paso (5).
1. Una *base de referencia* de un plan consiste en el historial de la instrucción SQL y sus planes en varios estados. La administración de planes de consultas puede tener en cuenta la base de referencia al elegir un plan, en función de si la opción usar base de referencia del plan está activada o no, de la siguiente manera.
+ Usar base de referencia del plan está “off” (desactivado) cuando `apg_plan_mgmt.use_plan_baselines` se establece con su valor predeterminado (`false`). El plan no se compara con la base de referencia antes de ejecutarse (A. Ejecutar el plan del optimizador).
+ Usar la base de referencia del plan está “on” (activado) cuando `apg_plan_mgmt.use_plan_baselines` se establece con su valor predeterminado (`true`). El plan se evalúa más a fondo con la base de referencia (6).
1. El plan se compara con otros planes para la instrucción en la base de referencia.
1. Si el plan del optimizador se encuentra entre los planes de la base de referencia, se comprueba su estado (7a).
1. Si el plan del optimizador no está entre los planes de la base de referencia, el plan se agrega a los planes para la instrucción como un plan `Unapproved` nuevo.
1. El estado del plan se verifica para determinar únicamente si no está aprobado.
1. Si el estado del plan es No aprobado, el costo estimado del plan se compara con el costo estimado especificado para el umbral del plan de ejecución no aprobado.
+ Si el costo estimado del plan está por debajo del umbral, el optimizador lo usa aunque sea un plan no aprobado (A. Ejecutar el plan del optimizador). Por lo general, el optimizador no ejecutará un plan no aprobado. Sin embargo, cuando el parámetro `apg_plan_mgmt.unapproved_plan_execution_threshold` especifica un valor de umbral de costo, el optimizador compara el costo del plan no aprobado con el umbral. Si el costo estimado es de menos del umbral, el optimizador ejecuta el plan. Para obtener más información, consulte [apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.unapproved_plan_execution_threshold).
+ Si el costo estimado del plan no está por debajo del umbral, se comprueban los demás atributos del plan (8a).
1. Si el estado del plan no está aprobado, se comprueban sus otros atributos (8a).
1. El optimizador no utilizará un plan desactivado. Es decir, el plan que tenga su atributo `enable` establecido en “f” (false). El optimizador tampoco utilizará un plan que tenga el estado Rechazado.
El optimizador no puede usar ningún plan que no sea válido. Los planes pueden dejar de ser válidos cuando se eliminan los objetos de los que dependen, como índices o particiones de tabla.
1. Si la instrucción tiene algún plan preferido habilitado y válido, el optimizador elige el que tenga costo mínimo de entre los planes preferidos almacenados para dicha instrucción SQL. A continuación, el optimizador ejecuta el plan preferido con costo mínimo.
1. Si el estado de cuenta no tiene ningún plan preferido habilitado y válido, se evalúa en el siguiente paso (9).
1. Si la instrucción tiene algún plan aprobado habilitado y válido, el optimizador elige el que tenga costo mínimo de entre los planes preferidos almacenados para dicha instrucción SQL. A continuación, el optimizador ejecuta el plan aprobado con costo mínimo.
Si la instrucción no tiene ningún plan aprobado válido y habilitado, el optimizador utiliza el plan de costo mínimo (A. Ejecutar el plan del optimizador).
# Examinación de los planes de consultas de Aurora PostgreSQL en la vista dba\$1plans
Los usuarios y administradores de bases de datos a los que se les ha otorgado el rol `apg_plan_mgmt` pueden ver y administrar los planes almacenados en `apg_plan_mgmt.dba_plans`. El administrador de un clúster de base de datos de Aurora PostgreSQL (alguien con permisos `rds_superuser`) debe conceder explícitamente este rol a los usuarios de la base de datos que tienen que trabajar con la administración de planes de consultas.
La vista `apg_plan_mgmt` contiene el historial del plan de todas las instrucciones SQL administradas para cada base de datos de la instancia de escritor del clúster de base de datos de Aurora PostgreSQL. Esta vista le permite examinar los planes, su estado, cuándo se utilizaron por última vez y todos los demás detalles relevantes.
Como ya hemos abordado en [Normalización y el hash SQL](AuroraPostgreSQL.Optimize.Start.md#AuroraPostgreSQL.Optimize.Start.hash-and-normalization), cada plan administrado se identifica mediante un valor hash SQL y un valor hash de plan combinado. Con estos identificadores, puede usar herramientas como Performance Insights de Amazon RDS para seguir el rendimiento individual de los planes. Para obtener más información sobre Información sobre el rendimiento, consulte [Using Amazon RDS performance insights]( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
## Descripción de planes administrados.
Para consultar una lista de los planes administrados, utilice una instrucción SELECT en la vista `apg_plan_mgmt.dba_plans`. El siguiente ejemplo muestra algunas columnas en la vista `dba_plans`, como el `status`, que identifica los planes aprobados y no aprobados.
```
SELECT sql_hash, plan_hash, status, enabled, stmt_name
FROM apg_plan_mgmt.dba_plans;
sql_hash | plan_hash | status | enabled | stmt_name
------------+-----------+------------+---------+------------
1984047223 | 512153379 | Approved | t | rangequery
1984047223 | 512284451 | Unapproved | t | rangequery
(2 rows)
```
Para facilitar la lectura, la consulta y el resultado que se muestran incluyen solo algunas de las columnas de la vista `dba_plans`. Para obtener información completa, consulte [Referencia de la vista apg\$1plan\$1mgmt.dba\$1plans para la edición compatible con Aurora PostgreSQL](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md).
# Mejora de los planes de consultas en Aurora PostgreSQL
Mejore la administración de los planes de consultas evaluando el rendimiento del plan y realizando correcciones. Para obtener más información sobre la mejora de los planes de consultas, vea los siguientes temas.
**Topics**
+ [Evaluación del rendimiento de los planes](#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance)
+ [Corrección de planes mediante pg\$1hint\$1plan](#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan)
## Evaluación del rendimiento de los planes
Después de que el optimizador capture los planes como sin aprobar, utilice la función `apg_plan_mgmt.evolve_plan_baselines` para comparar planes en función de su rendimiento real. Según el resultado de sus experimentos de rendimiento, podrá cambiar el estado de un plan de no aprobado a aprobado o rechazado. También puede decidir utilizar la función `apg_plan_mgmt.evolve_plan_baselines` para deshabilitar temporalmente un plan si no se ajusta a sus requisitos.
### Aprobar planes mejores
El siguiente ejemplo muestra cómo cambiar el estado de los planes administrados a aprobados mediante la función `apg_plan_mgmt.evolve_plan_baselines`.
```
SELECT apg_plan_mgmt.evolve_plan_baselines (
sql_hash,
plan_hash,
min_speedup_factor := 1.0,
action := 'approve'
)
FROM apg_plan_mgmt.dba_plans WHERE status = 'Unapproved';
```
```
NOTICE: rangequery (1,10000)
NOTICE: Baseline [ Planning time 0.761 ms, Execution time 13.261 ms]
NOTICE: Baseline+1 [ Planning time 0.204 ms, Execution time 8.956 ms]
NOTICE: Total time benefit: 4.862 ms, Execution time benefit: 4.305 ms
NOTICE: Unapproved -> Approved
evolve_plan_baselines
-----------------------
0
(1 row)
```
El resultado muestra un informe de rendimiento para la instrucción `rangequery` con vinculaciones de parámetros de 1 y 10 000. El nuevo plan no aprobado (`Baseline+1`) es mejor que el plan aprobado previamente (`Baseline`). Para confirmar que el nuevo plan sea ahora `Approved`, compruebe la vista `apg_plan_mgmt.dba_plans`.
```
SELECT sql_hash, plan_hash, status, enabled, stmt_name
FROM apg_plan_mgmt.dba_plans;
```
```
sql_hash | plan_hash | status | enabled | stmt_name
------------+-----------+----------+---------+------------
1984047223 | 512153379 | Approved | t | rangequery
1984047223 | 512284451 | Approved | t | rangequery
(2 rows)
```
El plan administrado incluye ahora dos planes aprobados que componen la base de referencia del plan de la instrucción. También puede llamar a la función `apg_plan_mgmt.set_plan_status` para establecer directamente el campo de estado de un plan en `'Approved'`, `'Rejected'`, `'Unapproved'` o `'Preferred'`.
### Rechazar o desactivar planes más lentos
Para rechazar o deshabilitar planes, pase `'reject'` o `'disable' ` como parámetro de acción a la función `apg_plan_mgmt.evolve_plan_baselines`. En este ejemplo se deshabilita cualquier plan capturado `Unapproved` que resulte al menos un 10 por ciento más lento que el mejor plan `Approved` para la instrucción.
```
SELECT apg_plan_mgmt.evolve_plan_baselines(
sql_hash, -- The managed statement ID
plan_hash, -- The plan ID
1.1, -- number of times faster the plan must be
'disable' -- The action to take. This sets the enabled field to false.
)
FROM apg_plan_mgmt.dba_plans
WHERE status = 'Unapproved' AND -- plan is Unapproved
origin = 'Automatic'; -- plan was auto-captured
```
También puede establecer un plan directamente como rechazado o deshabilitado. Para establecer directamente el campo habilitado de un plan como `true` o `false`, llame a la función `apg_plan_mgmt.set_plan_enabled`. Para establecer directamente el campo de estado de un plan como `'Approved'`, `'Rejected'`, `'Unapproved'` o `'Preferred'`, llame a la función `apg_plan_mgmt.set_plan_status`.
Para eliminar los planes que no son válidos y espera que sigan siendo inválidos, utilice la función `apg_plan_mgmt.validate_plans`. Esta función le permite eliminar o deshabilitar planes no válidos. Para obtener más información, consulte [Validación de planes](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
## Corrección de planes mediante pg\$1hint\$1plan
El optimizador de consultas está bien diseñado para encontrar un plan óptimo para todas las instrucciones, y en la mayoría de los casos el optimizador encuentra un plan bueno. Sin embargo, ocasionalmente podría detectar que existe un plan mucho mejor que el generado por el optimizador. Dos formas recomendadas de hacer que el optimizador genere un plan deseado son incluir la extensión `pg_hint_plan` o establecer variables de Grand Unified Configuration (GUC) en PostgreSQL:
+ Extensión `pg_hint_plan`: especifique un "consejo" para modificar cómo funciona el planificador mediante la extensión `pg_hint_plan` de PostgreSQL. Para instalar y obtener más información sobre cómo usar la extensión `pg_hint_plan`, consulte la [documentación de pg\$1hint\$1plan](https://github.com/ossc-db/pg_hint_plan).
+ Variables GUC: anule uno o varios parámetros del modelo de costos u otros parámetros del optimizador, como `from_collapse_limit` o `GEQO_threshold`.
Al usar una de estas técnicas para forzar que el optimizador de consultas utilice un plan, también puede utilizar la administración de planes de consulta para capturar y forzar el uso del nuevo plan.
Puede utilizar la extensión `pg_hint_plan` para cambiar el orden de las combinaciones, los métodos de combinación o las rutas de acceso para una instrucción SQL. Puede utilizar un comentario SQL con sintaxis `pg_hint_plan` especial para modificar cómo crea un plan el optimizador. Por ejemplo, supongamos que la instrucción SQL del problema tiene una combinación bidireccional.
```
SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
A continuación, suponga que el optimizador elige el orden de combinación (t1, t2), pero que sabe que el orden de combinación (t2, t1) es más rápido. El siguiente consejo fuerza al optimizador a utilizar el orden de combinación más rápido (t2, t1). Incluya EXPLAIN de modo que el optimizador genere un plan para la instrucción SQL pero sin ejecutar la instrucción. (No se muestra el resultado).
```
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Los siguientes pasos muestran cómo utilizar `pg_hint_plan`.
**Para modificar el plan generado por el optimizador y capturar el plan con pg\$1hint\$1plan**
1. Active el modo de captura manual.
```
SET apg_plan_mgmt.capture_plan_baselines = manual;
```
1. Especifique un consejo para la instrucción SQL que le interese.
```
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Tras la ejecución, el optimizador captura el plan en la vista `apg_plan_mgmt.dba_plans`. El plan capturado no incluye la sintaxis del comentario especial `pg_hint_plan` porque la administración del plan de consultas normaliza la instrucción eliminando los comentarios al principio.
1. Ver los planes administrados utilizando la vista `apg_plan_mgmt.dba_plans`.
```
SELECT sql_hash, plan_hash, status, sql_text, plan_outline
FROM apg_plan_mgmt.dba_plans;
```
1. Establezca el estado del plan en `Preferred`. De este modo, se asegurará de que el optimizador decida ejecutarlo en lugar de seleccionarlo del conjunto de planes aprobados cuando el plan de costo mínimo no sea ya `Approved` o `Preferred`.
```
SELECT apg_plan_mgmt.set_plan_status(sql-hash, plan-hash, 'preferred' );
```
1. Desactivar la captura de planes manual y forzar el uso de planes administrados.
```
SET apg_plan_mgmt.capture_plan_baselines = false;
SET apg_plan_mgmt.use_plan_baselines = true;
```
Ahora, cuando se ejecuta la instrucción SQL original, el optimizador elegirá un plan `Approved` o `Preferred`. Si el plan de costo mínimo no es `Approved` ni `Preferred`, el optimizador elegirá el plan `Preferred`.
# Eliminación de planes de consultas en Aurora PostgreSQL
Elimine los planes de ejecución que no esté usando o que no sean válidos. Para obtener más información sobre la eliminación de planes, consulte las siguientes secciones.
**Topics**
+ [Eliminación de planes](#AuroraPostgreSQL.Optimize.Maintenance.DeletingPlans)
+ [Validación de planes](#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans)
## Eliminación de planes
Los planes se eliminan automáticamente si no se usan en más de un mes, específicamente, 32 días. Este es el ajuste predeterminado del parámetro `apg_plan_mgmt.plan_retention_period`. Puede cambiar el período de retención del plan por otro más largo o por un período de tiempo más corto, a partir del valor de 1. Determinar el número de días desde que un plan se usó por última vez se usó restando la fecha de `last_used` de la fecha actual. La fecha de `last_used` es la fecha más reciente en que el optimizador eligió el plan como plan de costo mínimo o en que se ejecutó el plan. La fecha se almacena para el plan en la vista `apg_plan_mgmt.dba_plans`.
Le recomendamos que elimine planes que no se hayan utilizado durante mucho tiempo o que no resulten útiles. Todos los planes tienen una fecha `last_used` que utiliza el optimizador cada vez que ejecuta un plan o lo elige como plan de costo mínimo para una instrucción. Verifique las últimas fechas de `last_used`para identificar los planes que puede eliminar de forma segura.
La siguiente consulta devuelve una tabla de tres columnas con el recuento del número total de planes, los planes que no se han podido eliminar y los que se han eliminado correctamente. Incluye una consulta anidada que es un ejemplo de cómo usar la función `apg_plan_mgmt.delete_plan` para eliminar todos los planes que no se hayan seleccionado como plan de costo mínimo en los últimos 31 días y cuyo estado no es `Rejected`.
```
SELECT (SELECT COUNT(*) from apg_plan_mgmt.dba_plans) total_plans,
COUNT(*) FILTER (WHERE result = -1) failed_to_delete,
COUNT(*) FILTER (WHERE result = 0) successfully_deleted
FROM (
SELECT apg_plan_mgmt.delete_plan(sql_hash, plan_hash) as result
FROM apg_plan_mgmt.dba_plans
WHERE last_used < (current_date - interval '31 days')
AND status <> 'Rejected'
) as dba_plans ;
```
```
total_plans | failed_to_delete | successfully_deleted
-------------+------------------+----------------------
3 | 0 | 2
```
Para obtener más información, consulte [apg\$1plan\$1mgmt.delete\$1plan](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.delete_plan).
Para eliminar los planes que no son válidos y espera que sigan siendo inválidos, utilice la función `apg_plan_mgmt.validate_plans`. Esta función le permite eliminar o deshabilitar planes no válidos. Para obtener más información, consulte [Validación de planes](#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
**importante**
Si no elimina los planes extraños, podría quedarse eventualmente sin memoria compartida dedicada a la administración de planes de consulta. Para controlar cuánta memoria tendrá disponible para los planes administrados, utilice el parámetro `apg_plan_mgmt.max_plans`. Establezca este parámetro en el grupo de parámetros de base de datos personalizado y reinicie la instancia de base de datos para que los cambios surtan efecto. Para obtener más información, consulte el parámetro [apg\$1plan\$1mgmt.max\$1plans](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.max_plans).
## Validación de planes
Use la función `apg_plan_mgmt.validate_plans` para eliminar o deshabilitar planes no válidos.
Los planes pueden volverse no válidos u obsoletos cuando se eliminan los objetos de los que dependen, como un índice o una tabla. Sin embargo, puede que un plan deje de ser válido solo temporalmente si el objeto eliminado se recrea. Si un plan no válido puede pasar a ser válido posteriormente, es posible que prefiera deshabilitar un plan no válido o no hacer nada en lugar de eliminarlo.
Para encontrar y eliminar todos los planes que no sean válidos y no se hayan utilizado en la última semana, utilice la función `apg_plan_mgmt.validate_plans ` de la siguiente forma.
```
SELECT apg_plan_mgmt.validate_plans(sql_hash, plan_hash, 'delete')
FROM apg_plan_mgmt.dba_plans
WHERE last_used < (current_date - interval '7 days');
```
Para habilitar o deshabilitar un plan directamente, utilice la función `apg_plan_mgmt.set_plan_enabled`.
# Importación y exportación de planes administrados para Aurora PostgreSQL
Puede exportar sus planes administrados e importarlos en otra instancia de base de datos.
**Para exportar planes administrados.**
Un usuario autorizado puede copiar cualquier subconjunto de la tabla `apg_plan_mgmt.plans` a otra tabla, y después guardarlo mediante el comando `pg_dump`. A continuación se muestra un ejemplo.
```
CREATE TABLE plans_copy AS SELECT *
FROM apg_plan_mgmt.plans [ WHERE predicates ] ;
```
```
% pg_dump --table apg_plan_mgmt.plans_copy -Ft mysourcedatabase > plans_copy.tar
```
```
DROP TABLE apg_plan_mgmt.plans_copy;
```
**Para importar planes administrados.**
1. Copie el archivo .tar de los planes administrados exportados al sistema en el que desee restaurar los planes.
1. Utilice el comando `pg_restore` para copiar el archivo tar en una nueva tabla.
```
% pg_restore --dbname mytargetdatabase -Ft plans_copy.tar
```
1. Combine la tabla `plans_copy` con la tabla `apg_plan_mgmt.plans`, como se muestra en el siguiente ejemplo.
**nota**
En algunos casos, puede volcar de una versión de la extensión `apg_plan_mgmt` y restaurar a una versión diferente. En estos casos, las columnas de la tabla de planes puede ser diferente. De ser así, ponga un nombre explícito a las columnas en lugar de usar SELECT \$1.
```
INSERT INTO apg_plan_mgmt.plans SELECT * FROM plans_copy
ON CONFLICT ON CONSTRAINT plans_pkey
DO UPDATE SET
status = EXCLUDED.status,
enabled = EXCLUDED.enabled,
-- Save the most recent last_used date
--
last_used = CASE WHEN EXCLUDED.last_used > plans.last_used
THEN EXCLUDED.last_used ELSE plans.last_used END,
-- Save statistics gathered by evolve_plan_baselines, if it ran:
--
estimated_startup_cost = EXCLUDED.estimated_startup_cost,
estimated_total_cost = EXCLUDED.estimated_total_cost,
planning_time_ms = EXCLUDED.planning_time_ms,
execution_time_ms = EXCLUDED.execution_time_ms,
total_time_benefit_ms = EXCLUDED.total_time_benefit_ms,
execution_time_benefit_ms = EXCLUDED.execution_time_benefit_ms;
```
1. Vuelva a cargar los planes administrados en la memoria compartida y elimine la tabla de planes temporal.
```
SELECT apg_plan_mgmt.reload(); -- refresh shared memory
DROP TABLE plans_copy;
```
# Referencia de parámetros para la administración de planes de consultas de Aurora PostgreSQL
Puede configurar sus preferencias para la extensión `apg_plan_mgmt` mediante los parámetros que se indican en esta sección. Están disponibles en el parámetro de clúster de base de datos personalizado y en el grupo de parámetros de base de datos asociado al clúster de base de datos de Aurora PostgreSQL. Estos parámetros controlan el comportamiento de la función de administración de planes de consultas y cómo afecta al optimizador. Para obtener más información sobre la administración de planes de consultas, consulte [Activación de la administración de planes de consultas en Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md#AuroraPostgreSQL.Optimize.Enable). El cambio de los siguientes parámetros no tiene ningún efecto si la extensión `apg_plan_mgmt` no está configurada tal como se detalla en esa sección. Para obtener información acerca de cómo modificar los parámetros, consulte [Modificación de los parámetros en un grupo de parámetros de clúster de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md) y [Grupos de parámetros de base de datos para instancias de Amazon Aurora](USER_WorkingWithDBInstanceParamGroups.md).
**Topics**
+ [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines)
+ [apg\$1plan\$1mgmt.plan\$1capture\$1threshold](#AuroraPostgreSQL.Optimize.Parameters.plan_capture_threshold)
+ [apg\$1plan\$1mgmt.explain\$1hashes](#AuroraPostgreSQL.Optimize.Parameters.explain_hashes)
+ [apg\$1plan\$1mgmt.log\$1plan\$1enforcement\$1result](#AuroraPostgreSQL.Optimize.Parameters.log_plan_enforcement_result)
+ [apg\$1plan\$1mgmt.max\$1databases](#AuroraPostgreSQL.Optimize.Parameters.max_databases)
+ [apg\$1plan\$1mgmt.max\$1plans](#AuroraPostgreSQL.Optimize.Parameters.max_plans)
+ [apg\$1plan\$1mgmt.plan\$1hash\$1version](#AuroraPostgreSQL.Optimize.Parameters.plan_hash_version)
+ [apg\$1plan\$1mgmt.plan\$1retention\$1period](#AuroraPostgreSQL.Optimize.Parameters.plan_retention_period)
+ [apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold](#AuroraPostgreSQL.Optimize.Parameters.unapproved_plan_execution_threshold)
+ [apg\$1plan\$1mgmt.use\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Parameters.use_plan_baselines)
+ [auto\$1explain.hashes](#AuroraPostgreSQL.Optimize.Parameters.auto_explain.hashes)
## apg\$1plan\$1mgmt.capture\$1plan\$1baselines
Captura los planes de ejecución de consultas generados por el optimizador para cada instrucción SQL y los almacena en la vista `dba_plans`. De forma predeterminada, la cantidad máxima de planes que se puede almacenar es de 10 000, según lo especificado en el parámetro `apg_plan_mgmt.max_plans`. Para obtener información de referencia, consulte [apg\$1plan\$1mgmt.max\$1plans](#AuroraPostgreSQL.Optimize.Parameters.max_plans).
Puede establecer este parámetro en el grupo de parámetros de clúster de base de datos personalizado o en el grupo de parámetros de base de datos personalizado. Para cambiar el valor de este parámetro no es necesario reiniciar.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
Para obtener más información, consulte [Captura de planes de ejecución de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
## apg\$1plan\$1mgmt.plan\$1capture\$1threshold
Especifica el límite de modo que si el coste total del plan de ejecución de consultas es inferior a dicho límite, el plan no se incluirá en la vista `apg_plan_mgmt.dba_plans`.
Para cambiar el valor de este parámetro no es necesario reiniciar.
| Predeterminado | Valores permitidos | Descripción |
| --- | --- | --- |
| 0 | 0 - 1.79769e\$1308 | Establece el límite del coste total de ejecución del plan de consultas `apg_plan_mgmt` para incluir los planes. |
Para obtener más información, consulte [Examinación de los planes de consultas de Aurora PostgreSQL en la vista dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.explain\$1hashes
Especifica si `EXPLAIN [ANALYZE]` muestra `sql_hash` y `plan_hash` al final de su salida. Para cambiar el valor de este parámetro no es necesario reiniciar.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.log\$1plan\$1enforcement\$1result
Especifica si los resultados deben registrarse para ver si los planes administrados por QPM se utilizan correctamente. Cuando se utiliza un plan genérico almacenado, no se escribirán registros en los archivos de registro. Para cambiar el valor de este parámetro no es necesario reiniciar.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.max\$1databases
Especifica el número máximo de bases de datos de la instancia de escritor del clúster de base de datos de Aurora PostgreSQL que pueden usar la administración de planes de consultas. De forma predeterminada, la administración de planes de consultas puede admitir 10 bases de datos. Si tiene más de 10 bases de datos en la instancia, puede cambiar el valor de esta configuración. Para saber cuántas bases de datos hay en una instancia determinada, conéctese a la instancia mediante `psql`. A continuación, utilice el metacomando psql, `\l`, para enumerar las bases de datos.
Para cambiar el valor de este parámetro, es necesario reiniciar la instancia para que la configuración surta efecto.
| Predeterminado | Valores permitidos | Descripción |
| --- | --- | --- |
| 10 | 10-2147483647 | Número máximo de bases de datos que pueden usar la administración de planes de consultas en la instancia. |
Puede establecer este parámetro en el grupo de parámetros de clúster de base de datos personalizado o en el grupo de parámetros de base de datos personalizado.
## apg\$1plan\$1mgmt.max\$1plans
Establece el número máximo de instrucciones SQL que el administrador del plan de consultas puede mantener en la vista `apg_plan_mgmt.dba_plans`. Recomendamos establecer este parámetro en `10000` o superior para todas las versiones de Aurora PostgreSQL.
Puede establecer este parámetro en el grupo de parámetros de clúster de base de datos personalizado o en el grupo de parámetros de base de datos personalizado. Para cambiar el valor de este parámetro, es necesario reiniciar la instancia para que la configuración surta efecto.
| Predeterminado | Valores permitidos | Descripción |
| --- | --- | --- |
| 10000 | 10-2147483647 | Número máximo de planes que se pueden almacenar en la vista `apg_plan_mgmt.dba_plans`. El valor predeterminado para la versión 10 de Aurora PostgreSQL y las versiones previas es 1000. |
Para obtener más información, consulte [Examinación de los planes de consultas de Aurora PostgreSQL en la vista dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.plan\$1hash\$1version
Especifica los casos de uso para los que está diseñado el cálculo plan\$1hash. Una versión superior de `apg_plan_mgmt.plan_hash_version` abarca todas las funciones de la versión inferior. Por ejemplo, la versión 3 abarca los casos de uso admitidos por la versión 2.
El cambio del valor de este parámetro debe ir seguido de una llamada a `apg_plan_mgmt.validate_plans('update_plan_hash')`. Actualiza los valores de plan\$1hash de cada base de datos con apg\$1plan\$1mgmt instalado y las entradas de la tabla de planes. Para obtener más información, consulte [Validación de planes](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.plan\$1retention\$1period
Especifica el número de días que se van a conservar planes en la vista `apg_plan_mgmt.dba_plans`, tras el cual se eliminan automáticamente. De forma predeterminada, un plan se elimina cuando han transcurrido 32 días desde la última vez que se usó (la columna `last_used` en la vista `apg_plan_mgmt.dba_plans`). Puede cambiar esta configuración a cualquier número, de 1 o más.
Para cambiar el valor de este parámetro, es necesario reiniciar la instancia para que la configuración surta efecto.
| Predeterminado | Valores permitidos | Descripción |
| --- | --- | --- |
| 32 | 1-2147483647 | Número máximo de días desde que un plan se usó por última vez antes de que se elimine. |
Para obtener más información, consulte [Examinación de los planes de consultas de Aurora PostgreSQL en la vista dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold
Especifica un límite de coste por debajo del cual el optimizador puede utilizar un plan no aprobado. De forma predeterminada, el límite es 0, por lo que el optimizador no ejecuta planes sin aprobar. Si se establece este parámetro en un límite relativamente bajo, como 100, se evita la sobrecarga de los planes poco importantes. También puede establecer este parámetro en un valor extremadamente alto, como 10000000, utilizando el estilo reactivo de gestión de planes. Esto permite al optimizador utilizar todos los planes seleccionados sin sobrecargar el plan. Pero si encuentra un plan incorrecto, puede marcarlo manualmente como "rechazado" para que no se utilice la próxima vez.
El valor de este parámetro representa una estimación de costos para ejecutar un plan determinado. Si un plan no aprobado está por debajo de ese costo estimado, el optimizador lo usa para la instrucción SQL. Puedes ver los planes capturados y su estado (Aprobado, No aprobado) en la vista `dba_plans`. Para obtener más información, consulte [Examinación de los planes de consultas de Aurora PostgreSQL en la vista dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
Para cambiar el valor de este parámetro no es necesario reiniciar.
| Predeterminado | Valores permitidos | Descripción |
| --- | --- | --- |
| 0 | 0-2147483647 | Costo estimado del plan por debajo del cual se usa un plan no aprobado. |
Para obtener más información, consulte [Uso de los planes administrados de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md).
## apg\$1plan\$1mgmt.use\$1plan\$1baselines
Especifica que el optimizador debe usar uno de los planes aprobados capturados y almacenados en la vista `apg_plan_mgmt.dba_plans`. De forma predeterminada, este parámetro está desactivado (false), lo que provoca que el optimizador utilice el plan de menor costo que genera sin ninguna evaluación adicional. Al activar este parámetro (configurándolo en true) se fuerza al optimizador a elegir un plan de ejecución de consultas para la instrucción a partir de la línea base del plan. Para obtener más información, consulte [Uso de los planes administrados de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md). Para ver una imagen que detalle este proceso, consulte [Cómo elige el optimizador qué plan ejecutar.](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans).
Puede establecer este parámetro en el grupo de parámetros del clúster de base de datos personalizado o en el grupo de parámetros de base de datos personalizado. Para cambiar el valor de este parámetro no es necesario reiniciar.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
Puede evaluar los tiempos de respuesta de los diferentes planes capturados y cambiar el estado del plan, según sea necesario. Para obtener más información, consulte [Mejora de los planes de consultas en Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.md).
## auto\$1explain.hashes
Especifica si la salida auto\$1explain muestra sql\$1hash y plan\$1hash. Para cambiar el valor de este parámetro no es necesario reiniciar.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
# Referencia de funciones para la administración de planes de consultas de Aurora PostgreSQL
La extensión `apg_plan_mgmt` proporciona las siguientes funciones.
**Topics**
+ [apg\$1plan\$1mgmt.copy\$1outline](#AuroraPostgreSQL.Optimize.Functions.copy_outline)
+ [apg\$1plan\$1mgmt.delete\$1plan](#AuroraPostgreSQL.Optimize.Functions.delete_plan)
+ [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines)
+ [apg\$1plan\$1mgmt.get\$1explain\$1plan](#AuroraPostgreSQL.Optimize.Functions.get_explain_plan)
+ [apg\$1plan\$1mgmt.plan\$1last\$1used](#AuroraPostgreSQL.Optimize.Functions.plan_last_used)
+ [apg\$1plan\$1mgmt.reload](#AuroraPostgreSQL.Optimize.Functions.reload)
+ [apg\$1plan\$1mgmt.set\$1plan\$1enabled](#AuroraPostgreSQL.Optimize.Functions.set_plan_enabled)
+ [apg\$1plan\$1mgmt.set\$1plan\$1status](#AuroraPostgreSQL.Optimize.Functions.set_plan_status)
+ [apg\$1plan\$1mgmt.update\$1plans\$1last\$1used](#AuroraPostgreSQL.Optimize.Functions.update_plans_last_used)
+ [apg\$1plan\$1mgmt.validate\$1plans](#AuroraPostgreSQL.Optimize.Functions.validate_plans)
## apg\$1plan\$1mgmt.copy\$1outline
Copia un hash del plan SQL y un esquema del plan determinados en un hash del plan SQL y un esquema del plan de destino, por lo que sobrescribe el hash y el esquema del plan de destino. Esta función está disponible en las versiones 2.3 y posteriores de `apg_plan_mgmt`.
**Sintaxis**
```
apg_plan_mgmt.copy_outline(
source_sql_hash,
source_plan_hash,
target_sql_hash,
target_plan_hash,
force_update_target_plan_hash
)
```
**Valor devuelto**
Devuelve 0 si la copia se ha realizado correctamente. Genera excepciones para entradas no válidas.
**Parameters**
****
| Parámetro | Descripción |
| --- | --- |
| source\$1sql\$1hash | El identificador del sql\$1hash asociado al plan\$1hash para copiar la consulta de destino. |
| source\$1plan\$1hash | El identificador del plan\$1hash que se va a copiar a la consulta de destino. |
| target\$1sql\$1hash | El identificador del sql\$1hash de la consulta que se va a actualizar con el hash y el esquema del plan de origen. |
| target\$1plan\$1hash | El identificador del plan\$1hash de la consulta que se va a actualizar con el hash y el esquema del plan de origen. |
| force\$1update\$1target\$1plan\$1hash | (Opcional) El ID target\$1plan\$1hash de la consulta se actualiza incluso si el plan de origen no es reproducible para eltarget\$1sql\$1hash. Si se establece en true, la función se puede utilizar para copiar planes de varios esquemas en los que los nombres de las relaciones y las columnas sean coherentes. |
**Notas de uso**
Esta función le permite copiar un hash de plan y un esquema de plan que utiliza sugerencias a otras instrucciones similares, y le evita así tener que utilizar instrucciones de sugerencias en línea en cada ocurrencia en las instrucciones de destino. Si la consulta de destino actualizada da como resultado un plan no válido, esta función genera un error y revierte el intento de actualización.
## apg\$1plan\$1mgmt.delete\$1plan
Eliminar un plan administrado.
**Sintaxis**
```
apg_plan_mgmt.delete_plan(
sql_hash,
plan_hash
)
```
**Valor devuelto**
Devuelve 0 si la eliminación se ha realizado correctamente o -1 si en la eliminación se ha producido un error.
**Parameters**
****
| Parámetro | Descripción |
| --- | --- |
| sql\$1hash | El ID sql\$1hash de la instrucción SQL administrada por el plan. |
| plan\$1hash | El ID plan\$1hash del plan administrado. |
## apg\$1plan\$1mgmt.evolve\$1plan\$1baselines
Comprueba si un plan ya aprobado es más rápido o si un plan identificado por el optimizador de consultas como plan de costo mínimo es más rápido.
**Sintaxis**
```
apg_plan_mgmt.evolve_plan_baselines(
sql_hash,
plan_hash,
min_speedup_factor,
action
)
```
**Valor devuelto**
El número de planes que no han sido más rápidos que el mejor plan aprobado.
**Parameters**
****
| Parámetro | Descripción |
| --- | --- |
| sql\$1hash | El ID sql\$1hash de la instrucción SQL administrada por el plan. |
| plan\$1hash | El ID plan\$1hash del plan administrado. Utilice NULL para referirse a todos los planes que tengan el mismo valor del ID de sql\$1hash. |
| min\$1speedup\$1factor | El *factor de aceleración mínimo* es el número de veces más rápido que debe ser un plan en relación con los planes ya aprobados para aprobarlo. Este factor puede ser también el número de veces más lento que debe ser un plan para rechazarlo o deshabilitarlo. Este valor es un número flotante positivo. |
| action | La acción que va a realizar la función. Entre los valores válidos se incluyen los siguientes. No distingue entre mayúsculas y minúsculas. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) |
** Notas de uso**
Establecer planes específicos como aprobados, rechazados o deshabilitados en función de si el tiempo de planificación más el de ejecución es más rápido que el mejor plan aprobado por un factor que puede configurar. El parámetro de acción puede establecerse en `'approve'` o `'reject'` para aprobar o rechazar automáticamente un plan que cumpla los criterios de rendimiento. Como alternativa, podría establecerse como " (cadena vacía) para realizar el experimento de rendimiento y producir un informe, sin realizar ninguna acción.
Puede evitar una nueva ejecución sin sentido de la función `apg_plan_mgmt.evolve_plan_baselines` para un plan en el que se ha ejecutado recientemente. Para ello, restrinja los planes a los planes sin aprobar creados recientemente. Como alternativa, puede evitar la ejecución de la función `apg_plan_mgmt.evolve_plan_baselines` en cualquier plan aprobado que tenga una marca temporal `last_verified` reciente.
Realizar un experimento de rendimiento para comparar el tiempo de planificación más el de ejecución para cada plan en relación con los demás planes de la base de referencia. En algunos casos, solo hay un plan para una instrucción, y el plan está aprobado. En tal caso, compare el tiempo de planificación más ejecución del plan con el tiempo de planificación más ejecución de no usar ningún plan.
El beneficio (o desventaja) incremental de cada plan queda registrado en la vista `apg_plan_mgmt.dba_plans` de la columna `total_time_benefit_ms`. Si este valor es positivo, existe un beneficio de rendimiento medible al incluir este plan en la base de referencia.
Además de recopilar el tiempo de planificación y ejecución de cada plan candidato, la columna `last_verified` de la vista `apg_plan_mgmt.dba_plans` se actualiza con el `current_timestamp`. La marca temporal `last_verified` se podría utilizar para evitar la ejecución de esta función de nuevo en un plan cuyo rendimiento se haya verificado recientemente.
## apg\$1plan\$1mgmt.get\$1explain\$1plan
Genera el texto de una instrucción `EXPLAIN` para la instrucción SQL especificada.
**Sintaxis**
```
apg_plan_mgmt.get_explain_plan(
sql_hash,
plan_hash,
[explainOptionList]
)
```
**Valor devuelto**
Devuelve estadísticas de tiempo de ejecución para las instrucciones SQL especificadas. Utilizar sin `explainOptionList` para devolver un plan `EXPLAIN` simple.
**Parameters**
****
| Parámetro | Descripción |
| --- | --- |
| sql\$1hash | El ID sql\$1hash de la instrucción SQL administrada por el plan. |
| plan\$1hash | El ID plan\$1hash del plan administrado. |
| explainOptionList | Una lista separada por comas de opciones de explicación. Los valores válidos son `'analyze'`, `'verbose'`, `'buffers'`, `'hashes'` y `'format json'`. Si la lista de `explainOptionList` es NULL o una cadena vacía (''), esta función genera una instrucción `EXPLAIN`, sin ninguna estadística. |
**Notas de uso**
Para `explainOptionList`, puede usar cualquiera de las mismas opciones que usaría con una instrucción `EXPLAIN`. El optimizador de Aurora PostgreSQL concatena la lista de opciones que proporciona a la instrucción `EXPLAIN`.
## apg\$1plan\$1mgmt.plan\$1last\$1used
Devuelve la fecha `last_used` del plan especificado de la memoria compartida.
**nota**
El valor de la memoria compartida siempre es actual en la instancia de base de datos principal del clúster de base de datos. El valor solo se vacía periódicamente en la columna `last_used` de la vista `apg_plan_mgmt.dba_plans`.
**Sintaxis**
```
apg_plan_mgmt.plan_last_used(
sql_hash,
plan_hash
)
```
**Valor devuelto**
Devuelve la fecha `last_used`.
**Parameters**
****
| Parámetro | Descripción |
| --- | --- |
| sql\$1hash | El ID sql\$1hash de la instrucción SQL administrada por el plan. |
| plan\$1hash | El ID plan\$1hash del plan administrado. |
## apg\$1plan\$1mgmt.reload
Vuelve a cargar los planes en la memoria compartida desde la vista `apg_plan_mgmt.dba_plans`.
**Sintaxis**
```
apg_plan_mgmt.reload()
```
**Valor devuelto**
Ninguno.
**Parameters**
Ninguna.
** Notas de uso**
Llame a `reload` para las siguientes situaciones:
+ Utilícelo para actualizar la memoria compartida de una réplica de solo lectura inmediatamente, en lugar de esperar a que los nuevos planes propaguen la réplica.
+ Se utiliza tras importar los planes administrados.
## apg\$1plan\$1mgmt.set\$1plan\$1enabled
Habilitar o deshabilitar un plan administrado.
**Sintaxis**
```
apg_plan_mgmt.set_plan_enabled(
sql_hash,
plan_hash,
[true | false]
)
```
**Valor devuelto**
Devuelve 0 si el ajuste se ha realizado correctamente o -1 si en el ajuste se ha producido un error.
**Parameters**
****
| Parámetro | Descripción |
| --- | --- |
| sql\$1hash | El ID sql\$1hash de la instrucción SQL administrada por el plan. |
| plan\$1hash | El ID plan\$1hash del plan administrado. |
| enabled | Valor booleano de verdadero o falso: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) |
## apg\$1plan\$1mgmt.set\$1plan\$1status
Establezca el estado de un plan administrado en `Approved`, `Unapproved`, `Rejected` o `Preferred`.
**Sintaxis**
```
apg_plan_mgmt.set_plan_status(
sql_hash,
plan_hash,
status
)
```
**Valor devuelto**
Devuelve 0 si el ajuste se ha realizado correctamente o -1 si en el ajuste se ha producido un error.
**Parameters**
****
| Parámetro | Descripción |
| --- | --- |
| sql\$1hash | El ID sql\$1hash de la instrucción SQL administrada por el plan. |
| plan\$1hash | El ID plan\$1hash del plan administrado. |
| status | Cadena con uno de los siguientes valores: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) El caso que utilice no importa, pero el valor de estado se establece en mayúscula inicial en la vista `apg_plan_mgmt.dba_plans`. Para obtener más información acerca de estos valores de la tarea, consulte `status` en [Referencia de la vista apg\$1plan\$1mgmt.dba\$1plans para la edición compatible con Aurora PostgreSQL](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md). |
## apg\$1plan\$1mgmt.update\$1plans\$1last\$1used
Actualiza inmediatamente la tabla de planes con la fecha de `last_used` almacenada en la memoria compartida.
**Sintaxis**
```
apg_plan_mgmt.update_plans_last_used()
```
**Valor devuelto**
Ninguno.
**Parameters**
Ninguna.
** Notas de uso**
Llame a `update_plans_last_used` para asegurarse de que las consultas de la columna `dba_plans.last_used` utilizan la información más actualizada. Si el archivo de la fecha de `last_used` no se actualiza inmediatamente, un proceso en segundo plano actualiza la tabla de planes con la fecha de `last_used` una vez cada hora (de forma predeterminada).
Por ejemplo, si una instrucción con un `sql_hash` determinado comienza a ejecutarse lentamente, puede determinar qué planes para esa instrucción se ejecutaron desde que comenzó la regresión de rendimiento. Para ello, primero vacíe los datos de la memoria compartida al disco para que las fechas de `last_used` estén actualizadas y, a continuación, consulte todos los planes de `sql_hash` de la instrucción con la regresión del rendimiento. En la consulta, asegúrese de que la fecha de `last_used` es superior o igual que la fecha en que comenzó la regresión del rendimiento. La consulta identifica el plan o conjunto de planes que podrían ser responsables de la regresión del rendimiento. Puede usar `apg_plan_mgmt.get_explain_plan` con `explainOptionList` establecidos en `verbose, hashes`. También puede utilizar `apg_plan_mgmt.evolve_plan_baselines` para analizar el plan y cualquier plan alternativo que pueda funcionar mejor.
La función `update_plans_last_used` tiene efecto únicamente en la instancia de base de datos principal del clúster de base de datos.
## apg\$1plan\$1mgmt.validate\$1plans
Validar que el optimizador aún puede recrear planes. El optimizador valida los planes `Approved`, `Unapproved` y `Preferred`, aunque el plan esté habilitado o deshabilitado. Los planes `Rejected` no se validan. Opcionalmente, puede usar la función `apg_plan_mgmt.validate_plans` para eliminar o deshabilitar planes no válidos.
**Sintaxis**
```
apg_plan_mgmt.validate_plans(
sql_hash,
plan_hash,
action)
apg_plan_mgmt.validate_plans(
action)
```
**Valor devuelto**
Número de planes no válidos.
**Parameters**
****
| Parámetro | Descripción |
| --- | --- |
| sql\$1hash | El ID sql\$1hash de la instrucción SQL administrada por el plan. |
| plan\$1hash | El ID plan\$1hash del plan administrado. Utilice NULL para referirse a todos los planes para el mismo valor del ID de sql\$1hash. |
| action | La acción que va a realizar la función para los planes no válidos. Entre los valores de cadena válidos se incluyen los siguientes. No distingue entre mayúsculas y minúsculas. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) Cualquier otro valor se trata como una cadena vacía. |
**Notas de uso**
Utilice el formulario `validate_plans(action)` para validar todos los planes administrados para las instrucciones administradas en toda la vista `apg_plan_mgmt.dba_plans`.
Utilice el formulario `validate_plans(sql_hash, plan_hash, action)` para validar un plan administrado especificado con `plan_hash`, para una instrucción administrada especificada con `sql_hash`.
Utilice el formulario `validate_plans(sql_hash, NULL, action)` para validar todos los planes administrados para una instrucción administrada especificada con `sql_hash`.
# Referencia de la vista apg\$1plan\$1mgmt.dba\$1plans para la edición compatible con Aurora PostgreSQL
Las columnas de la información del plan en la vista `apg_plan_mgmt.dba_plans` incluyen lo siguiente.
| Columna dba\$1plans | Descripción |
| --- | --- |
| cardinality\$1error | Medición del error entre la cardinalidad estimada contra la cardinalidad real. La *cardinalidad* es el número de filas de la tabla que procesará el plan. Si el error de cardinalidad es grande, aumenta la probabilidad de que el plan no resulte óptimo. Esta columna se rellena mediante la función [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| compatibility\$1level | Este parámetro muestra cuándo se validó por última vez un plan de consultas. En las versiones 12.19, 13.15, 14.12, 15.7, 16.3 y posteriores de Aurora PostgreSQL, se muestra el número de versión de Aurora. Para versiones anteriores, muestra un número de versión específico de la característica. Mantenga este valor de parámetro en su valor predeterminado. Aurora PostgreSQL establece y actualiza automáticamente este valor. |
| created\$1by | El usuario autenticado (session\$1user) que ha creado el plan. |
| enabled | Un indicador de si el plan está habilitado o deshabilitado. Todos los planes están habilitados de forma predeterminada. Puede deshabilitar los planes para evitar que el optimizador los use. Para modificar este valor, use la función [apg\$1plan\$1mgmt.set\$1plan\$1enabled](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.set_plan_enabled). |
| environment\$1variables | Los parámetros y valores Grand Unified Configuration (GUC) de PostgreSQL que ha anulado el optimizador en el momento de capturar el plan. |
| estimated\$1startup\$1cost | El costo de configuración del optimizador estimado antes de que entregue las filas de una tabla. |
| estimated\$1total\$1cost | El costo de configuración del optimizador estimado para entregar la última fila de una tabla. |
| execution\$1time\$1benefit\$1ms | El beneficio en tiempo de ejecución, en milisegundos, de habilitar el plan. Esta columna se rellena mediante la función [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| execution\$1time\$1ms | El tiempo estimado, en milisegundos, que se ejecutaría el plan. Esta columna se rellena mediante la función [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| has\$1side\$1effects | Un valor que indica que la instrucción SQL es una instrucción en lenguaje de manipulación de datos (DML) o una instrucción SELECT que contiene una función VOLATILE. |
| last\$1used | Este valor se actualiza a la fecha actual siempre que el plan sea ejecutado o cuando el plan sea el plan de costo mínimo del optimizador de consultas. Este valor se almacena en la memoria compartida y se vacía en el disco periódicamente. Para obtener el valor más actualizado, lea la fecha de la memoria compartida llamando a la función apg\$1plan\$1mgmt.plan\$1last\$1used(sql\$1hash, plan\$1hash) en lugar de leer el valor last\$1used. Para obtener más información, consulte el parámetro [apg\$1plan\$1mgmt.plan\$1retention\$1period](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.plan_retention_period). |
| last\$1validated | La fecha y hora más recientes en las que se comprobó que el plan se podría recrear mediante la función [apg\$1plan\$1mgmt.validate\$1plans](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.validate_plans) o la función [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| last\$1verified | La fecha y hora más recientes en las que se verificó un plan como el que mejor rendimiento ofrece para los parámetros especificados mediante la función [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| origin | Cómo se capturó el plan con el parámetro [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines). Entre los valores válidos se incluyen los siguientes: `M`: el plan se capturó mediante captura de planes manual. `A`: el plan se capturó mediante captura de planes automática. |
| param\$1list | Los valores de parámetros que se pasaron a la instrucción si es una instrucción preparada. |
| plan\$1created | La fecha y hora en que se creó el plan. |
| plan\$1hash | El identificador del plan. La combinación de plan\$1hash y sql\$1hash identifica un plan específico de forma unívoca. |
| plan\$1outline | Una representación del plan que se utiliza para recrear el plan de ejecución real, y es independiente de la base de datos. Los operadores del árbol se corresponden con los operadores que aparecen en el resultado de EXPLAIN. |
| planning\$1time\$1ms | El tiempo real de ejecución del planificador, en milisegundos. Esta columna se rellena mediante la función [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| queryId | Un hash de instrucción, calculado por la extensión pg\$1stat\$1statements. No es un identificador estable ni independiente de la base de datos, ya que depende de los identificadores de objetos (OID). El valor será 0 si compute\$1query\$1id está off al capturar el plan de consulta. |
| sql\$1hash | Un valor hash del texto de la instrucción SQL, normalizado con los literales eliminados. |
| sql\$1text | El texto completo de la instrucción SQL. |
| status | El estado de un plan, que determina cómo utiliza un plan el optimizador. Entre los valores válidos se incluyen los siguientes. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.dba_plans_view_Reference.html) |
| stmt\$1name | El nombre de la instrucción SQL dentro de una instrucción PREPARE. Este valor es una cadena vacía para una instrucción preparada sin nombre. Este valor es NULL para una instrucción no preparada. |
| total\$1time\$1benefit\$1ms | El beneficio en tiempo total, en milisegundos, de habilitar este plan. Este valor tiene en cuenta tanto el tiempo de planificación como el de ejecución. Si este valor es negativo, existe una desventaja al habilitar este plan. Esta columna se rellena mediante la función [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
# Funciones avanzadas de la administración de planes de consultas
A continuación, encontrará información sobre las funciones avanzadas de la administración de planes de consulta (QPM) de Aurora PostgreSQL:
**Topics**
+ [Captura de planes de ejecución de Aurora PostgreSQL en réplicas](AuroraPostgreSQL.QPM.Plancapturereplicas.md)
+ [Compatibilidad con partición de tablas](AuroraPostgreSQL.QPM.Partitiontable.md)
# Captura de planes de ejecución de Aurora PostgreSQL en réplicas
QPM (Administración de planes de consultas) le permite capturar los planes de consultas generados por las réplicas de Aurora y los almacena en la instancia de base de datos principal del clúster de base de datos de Aurora. Puede recopilar los planes de consultas de todas las réplicas de Aurora y mantener un conjunto de planes óptimos en una tabla persistente central en la instancia principal. A continuación, puede aplicar estos planes a otras réplicas cuando lo necesite. De este modo, se mantiene la estabilidad de los planes de ejecución y se mejora el rendimiento de las consultas en todos los clústeres de bases de datos y versiones del motor.
**Topics**
+ [Requisitos previos](#AuroraPostgreSQL.QPM.Plancapturereplicas.Prereq)
+ [Administrar la captura de planes para réplicas de Aurora](#AuroraPostgreSQL.QPM.Plancapturereplicas.managing)
+ [Solución de problemas](#AuroraPostgreSQL.QPM.Plancapturereplicas.Troubleshooting)
## Requisitos previos
**Activar `capture_plan_baselines parameter` en una réplica de Aurora**: establezca el parámetro `capture_plan_baselines` en automático o manual para capturar los planes en las réplicas de Aurora. Para obtener más información, consulte [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines).
**Instalar la extensión postgres\$1fdw**: debe instalar la extensión de contenedor de datos externos `postgres_fdw` para capturar los planes en las réplicas de Aurora. Para instalar la extensión, ejecute el siguiente comando en cada base de datos:
```
postgres=> CREATE EXTENSION IF NOT EXISTS postgres_fdw;
```
## Administrar la captura de planes para réplicas de Aurora
**Activar la captura de planes para réplicas de Aurora**
Debe tener privilegios de `rds_superuser` para crear o eliminar la captura de planes en las réplicas de Aurora. Para obtener más información sobre los roles de usuario y los permisos, consulte [Descripción de los roles y permisos de PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Roles.html).
Para capturar planes, llame a la función apg\$1plan\$1mgmt.create\$1replica\$1plan\$1capture en la instancia de base de datos del escritor, como se muestra a continuación:
```
postgres=> CALL apg_plan_mgmt.create_replica_plan_capture('endpoint', 'password');
```
+ punto de conexión: el punto de conexión o cluster\$1endpoint del escritor de la base de datos global de Aurora proporciona compatibilidad con la conmutación por error para la captura de planes en réplicas de Aurora.
Para obtener más información sobre el punto de conexión del escritor de la base de datos global de Aurora, consulte [Visualización de los puntos de conexión de una base de datos global de Amazon Aurora](aurora-global-database-connecting.md#viewing-endpoints).
Para obtener más información sobre los puntos de conexión del clúster, consulte [Puntos de conexión de clúster para Amazon Aurora](Aurora.Endpoints.Cluster.md).
+ contraseña: le recomendamos que siga las siguientes indicaciones para crear una contraseña y mejorar la seguridad:
+ Debe contener al menos 8 caracteres únicos.
+ Debe contener al menos una letra en mayúsculas, una letra en minúsculas y un número.
+ Debe tener al menos un carácter especial (`?`, `!`, `#`, `<`, `>`, `*`, etc.).
**nota**
Si cambia el punto de conexión, la contraseña o el número de puerto, debe volver a ejecutar `apg_plan_mgmt.create_replica_plan_capture()` con el punto de conexión y la contraseña para iniciar la captura de planes de nuevo. De lo contrario, no se podrán capturar los planes de las réplicas de Aurora.
**Desactivar la captura de planes para réplicas de Aurora**
Puede desactivar el parámetro `capture_plan_baselines` en la réplica de Aurora estableciendo su valor en `off` en el grupo de parámetros.
**Eliminar la captura de planes para réplicas de Aurora**
Puede eliminar completamente la captura de planes en las réplicas de Aurora, pero asegúrese antes de hacerlo. Para eliminar la captura de planes, llame a `apg_plan_mgmt.remove_replica_plan_capture` como se muestra a continuación:
```
postgres=> CALL apg_plan_mgmt.remove_replica_plan_capture();
```
Debe volver a llamar a apg\$1plan\$1mgmt.create\$1replica\$1plan\$1capture() para activar la captura de planes en las réplicas de Aurora con el punto de conexión y la contraseña.
## Solución de problemas
A continuación, puede encontrar ideas para resolver problemas y soluciones si el plan no se captura en las réplicas de Aurora como se esperaba.
+ **Configuración de parámetros**: compruebe si el parámetro `capture_plan_baselines` está establecido en el valor adecuado para activar la captura de planes.
+ **Instalación de la extensión `postgres_fdw`**: utilice la siguiente consulta para comprobar si se ha instalado `postgres_fdw`.
```
postgres=> SELECT * FROM pg_extension WHERE extname = 'postgres_fdw'
```
+ **Llamada a create\$1replica\$1plan\$1capture()**: utilice el siguiente comando para comprobar si se ha activado el mapeo de usuarios. De lo contrario, llame a `create_replica_plan_capture()` para iniciar la función.
```
postgres=> SELECT * FROM pg_foreign_server WHERE srvname = 'apg_plan_mgmt_writer_foreign_server';
```
+ **Punto de conexión y número de puerto**: compruebe si el punto de conexión y el número de puerto son correctos. Si no lo son, no se mostrará ningún mensaje de error.
Usa el siguiente comando para comprobar el punto de conexión utilizado en create() y ver en qué base de datos está alojado:
```
postgres=> SELECT srvoptions FROM pg_foreign_server WHERE srvname = 'apg_plan_mgmt_writer_foreign_server';
```
+ **reload ()**: debe llamar a apg\$1plan\$1mgmt.reload() después de llamar a apg\$1plan\$1mgmt.delete\$1plan() en las réplicas de Aurora para que la función de eliminación sea efectiva. Esto garantiza que el cambio se haya implementado correctamente.
+ **Contraseña**: debe introducir la contraseña en create\$1replica\$1plan\$1capture() según las pautas mencionadas. De lo contrario, se producirá un error. Para obtener más información, consulte [Administrar la captura de planes para réplicas de Aurora](#AuroraPostgreSQL.QPM.Plancapturereplicas.managing). Utilice otra contraseña que se ajuste a los requisitos.
+ **Conexión entre regiones**: la captura de planes en réplicas de Aurora también se admite en la base de datos global de Aurora, donde la instancia de escritor y las réplicas de Aurora pueden estar en diferentes regiones. Asegúrese de utilizar el punto de conexión del escritor de la base de datos global de Aurora para mantener la conectividad después de eventos de conmutación por error o transición. Para obtener más información sobre los puntos de conexión de la base de datos global de Aurora, consulte [Visualización de los puntos de conexión de una base de datos global de Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-connecting.html#viewing-endpoints). La instancia de escritor y la réplica entre regiones deben poder comunicarse mediante emparejamiento de VPC. Para obtener más información, consulte [Interconexión de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html). Si se produce una conmutación por error entre regiones, debe volver a configurar el punto de conexión para convertirlo en un nuevo punto de conexión del clúster de base de datos principal.
**nota**
Cuando utilice un punto de conexión de clúster en lugar de un punto de conexión de escritor de base de datos global de Aurora, tendrá que actualizar el punto de conexión de clúster después de realizar una operación de conmutación por error o transición global.
# Compatibilidad con partición de tablas
La administración de planes de consulta (QPM) de Aurora PostgreSQL admite particiones de tablas declarativas en las siguientes versiones:
+ Versión 15.3 y versiones posteriores a la 15
+ Versión 14.8 y versiones posteriores a la 14
+ Versión 13.11 y versiones posteriores a la 13
Para obtener más información, consulte [Table Partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html).
**Topics**
+ [Configuración de la partición de tablas](#AuroraPostgreSQL.QPM.Partitiontable.setup)
+ [Captura de planos para la partición de tablas](#AuroraPostgreSQL.QPM.Partitiontable.capture)
+ [Aplicación de un plan de partición de tablas](#AuroraPostgreSQL.QPM.Partitiontable.enforcement)
+ [Convención de nomenclatura](#AuroraPostgreSQL.QPM.Partitiontable.naming.convention)
## Configuración de la partición de tablas
Para configurar la partición de tablas en QPMde Aurora PostgreSQL, haga lo siguiente:
1. Establezca `apg_plan_mgmt.plan_hash_version` en 3 o más en el grupo de parámetros del clúster de base de datos.
1. Navegue hasta una base de datos que utilice QPM y tenga entradas en la vista `apg_plan_mgmt.dba_plans`.
1. Llame a `apg_plan_mgmt.validate_plans('update_plan_hash')` para actualizar el valor `plan_hash` en la tabla de planes.
1. Repita los pasos 2 y 3 para todas las bases de datos con administración del plan de consultas habilitada que tengan entradas e la vista `apg_plan_mgmt.dba_plans`.
Para obtener más información sobre estos parámetros, consulte [Referencia de parámetros para la administración de planes de consultas de Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Parameters.md).
## Captura de planos para la partición de tablas
En QPM, los diferentes planes se distinguen por su valor de `plan_hash`. Para entender cómo cambia `plan_hash`, primero hay que entender planes similares.
La combinación de métodos de acceso, nombres de índice sin dígitos y nombres de particiones sin dígitos, acumulados en el nivel del nodo Append, debe ser constante para que los planes se consideren iguales. Las particiones específicas a las que se accede en los planos no son significativas. En el ejemplo siguiente, se crea una tabla `tbl_a` con 4 particiones.
```
postgres=>create table tbl_a(i int, j int, k int, l int, m int) partition by range(i);
CREATE TABLE
postgres=>create table tbl_a1 partition of tbl_a for values from (0) to (1000);
CREATE TABLE
postgres=>create table tbl_a2 partition of tbl_a for values from (1001) to (2000);
CREATE TABLE
postgres=>create table tbl_a3 partition of tbl_a for values from (2001) to (3000);
CREATE TABLE
postgres=>create table tbl_a4 partition of tbl_a for values from (3001) to (4000);
CREATE TABLE
postgres=>create index t_i on tbl_a using btree (i);
CREATE INDEX
postgres=>create index t_j on tbl_a using btree (j);
CREATE INDEX
postgres=>create index t_k on tbl_a using btree (k);
CREATE INDEX
```
Los siguientes planes se consideran iguales porque se utiliza un único método de examen para examinar `tbl_a` independientemente del número de particiones que revise la consulta.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 999 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------
Seq Scan on tbl_a1 tbl_a
Filter: ((i >= 990) AND (i <= 999) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(3 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(6 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a3 tbl_a_3
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(8 rows)
```
Los siguientes 3 planes también se consideran iguales porque, en el nivel principal, los métodos de acceso, los nombres de índice sin dígitos y los nombres de las particiones sin dígitos son `SeqScan tbl_a`, `IndexScan (i_idx) tbl_a`.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a2_i_idx on tbl_a2 tbl_a_2
Index Cond: ((i >= 990) AND (i <= 1100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(7 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(10 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a3 tbl_a_3
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a4_i_idx on tbl_a4 tbl_a_4
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(11 rows)
```
Independientemente del diferente orden y número de ocurrencias en las particiones secundarias, los métodos de acceso, los nombres de índice sin dígitos y los nombres de las particiones sin dígitos son constantes en el nivel principal para cada uno de los planes anteriores.
Sin embargo, los planes se considerarán diferentes si se cumple alguna de las siguientes condiciones:
+ Se utiliza algún método de acceso adicional en el plan.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Bitmap Heap Scan on tbl_a3 tbl_a_3
Recheck Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a3_i_idx
Index Cond: ((i >= 990) AND (i <= 2100))
SQL Hash: 1553185667, Plan Hash: 1134525070
(11 rows)
```
+ Se deja de utilizar alguno de los métodos de acceso del plan.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(6 rows)
```
+ Se cambia el índice asociado a un método de índice.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a2_j_idx on tbl_a2 tbl_a_2
Index Cond: (j < 9910)
Filter: ((i >= 990) AND (i <= 1100) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993343726
(7 rows)
```
## Aplicación de un plan de partición de tablas
Los planes aprobados para tablas particionadas se aplican mediante correspondencia posicional. Los planes no son específicos de las particiones y se pueden aplicar a particiones distintas de los planes a los que se hace referencia en la consulta original. Los planes también pueden aplicarse a las consultas que accedan a un número de particiones diferente al esquema original aprobado.
Por ejemplo, si el esquema aprobado es para el siguiente plan:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(10 rows)
```
A continuación, este plan también se puede aplicar a las consultas SQL que hagan referencia a 2, 4 o más particiones. Los posibles planes que podrían surgir de estos escenarios para el acceso a 2 y 4 particiones son:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
----------------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 1100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(8 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a4 tbl_a_4
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(12 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
----------------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Index Scan using tbl_a4_i_idx on tbl_a4 tbl_a_4
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(14 rows)
```
Considere otro plan aprobado con diferentes métodos de acceso para cada partición:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Bitmap Heap Scan on tbl_a3 tbl_a_3
Recheck Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a3_i_idx
Index Cond: ((i >= 990) AND (i <= 2100))
SQL Hash: 1553185667, Plan Hash: 2032136998
(12 rows)
```
En este caso, cualquier plan que lea de dos particiones no podría aplicarse. A menos que se puedan utilizar todas las combinaciones (método de acceso, nombre de índice) del plan aprobado, no se puede aplicar el plan. Por ejemplo, los siguientes planes tienen distintos hashes de plan y el plan aprobado no se puede aplicar en estos casos:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1900 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------------
Append
-> Bitmap Heap Scan on tbl_a1 tbl_a_1
Recheck Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a1_i_idx
Index Cond: ((i >= 990) AND (i <= 1900))
-> Bitmap Heap Scan on tbl_a2 tbl_a_2
Recheck Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a2_i_idx
Index Cond: ((i >= 990) AND (i <= 1900))
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: 1553185667, Plan Hash: -568647260
(13 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1900 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1900) AND (j < 9910) AND (k > 50))
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: 1553185667, Plan Hash: -496793743
(8 rows)
```
## Convención de nomenclatura
Para que QPM aplique un plan con tablas particionadas declarativas, debe seguir reglas de nomenclatura específicas para las tablas principales, las particiones de tablas y los índices:
+ **Nombres de las tablas principales**: estos nombres deben diferir en letras de alfabeto o caracteres especiales y no solo en dígitos. Por ejemplo, tA, tB y tC son nombres aceptables para tablas principales independientes, mientras que t1, t2 y t3 no lo son.
+ **Nombres de tablas de particiones individuales**: las particiones del mismo elemento principal solo deben diferir entre sí en dígitos. Por ejemplo, los nombres de partición aceptables de tA podrían ser tA1, tA2 o t1A, t2A o incluso varios dígitos.
Cualquier otra diferencia (letras, caracteres especiales) no garantizará la aplicación del plan.
+ **Nombres de índice**: en la jerarquía de tablas de particiones, asegúrese de que todos los índices tengan nombres únicos. Esto significa que las partes no numéricas de los nombres deben ser diferentes. Por ejemplo, si tiene una tabla particionada nombrada `tA` con un nombre de índice `tA_col1_idx1`, no puede tener otro índice nombrado `tA_col1_idx2`. Sin embargo, puede tener un índice llamado `tA_a_col1_idx2` porque la parte no numérica del nombre es única. Esta regla se aplica a los índices creados tanto en la tabla principal como en las tablas de particiones individuales.
El incumplimiento de las convenciones de nomenclatura anteriores puede provocar que los planes aprobados no se apliquen. El siguiente ejemplo ilustra un error de ejecución de este tipo:
```
postgres=>create table t1(i int, j int, k int, l int, m int) partition by range(i);
CREATE TABLE
postgres=>create table t1a partition of t1 for values from (0) to (1000);
CREATE TABLE
postgres=>create table t1b partition of t1 for values from (1001) to (2000);
CREATE TABLE
postgres=>SET apg_plan_mgmt.capture_plan_baselines TO 'manual';
SET
postgres=>explain (hashes true, costs false) select count(*) from t1 where i > 0;
QUERY PLAN
--------------------------------------------------------------------------
Aggregate
-> Append
-> Seq Scan on t1a t1_1
Filter: (i > 0)
-> Seq Scan on t1b t1_2
Filter: (i > 0)
SQL Hash: -1720232281, Plan Hash: -1010664377
(7 rows)
```
```
postgres=>SET apg_plan_mgmt.use_plan_baselines TO 'on';
SET
postgres=>explain (hashes true, costs false) select count(*) from t1 where i > 1000;
QUERY PLAN
-------------------------------------------------------------------------
Aggregate
-> Seq Scan on t1b t1
Filter: (i > 1000)
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: -1720232281, Plan Hash: 335531806
(5 rows)
```
Aunque los dos planes parezcan idénticos, sus valores `Plan Hash` son diferentes debido a los nombres de las tablas secundarias. Los nombres de las tablas varían en caracteres alfabéticos y no solo en dígitos, lo que provoca un error de cumplimiento.