Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Gestione dei piani di esecuzione delle query per Aurora PostgreSQL
La gestione del piano di query per Aurora PostgreSQL è una funzionalità opzionale che è possibile utilizzare con il cluster database Edizione compatibile con PostgreSQL di Amazon Aurora. Questa funzionalità è nel pacchetto come estensione `apg_plan_mgmt` che puoi installare nel cluster database Aurora PostgreSQL. La gestione del piano di query consente di gestire i piani di esecuzione delle query generati dall'ottimizzatore per le applicazioni SQL. L'`apg_plan_mgmt` AWS estensione si basa sulla funzionalità nativa di elaborazione delle query del motore di database PostgreSQL.
Di seguito, sono disponibili informazioni sulle funzionalità di gestione del piano di query per Aurora PostgreSQL, su come configurarlo e su come utilizzarlo con il cluster database Aurora PostgreSQL. Prima di iniziare, ti consigliamo di leggere tutte le note di rilascio per la versione specifica dell'estensione `apg_plan_mgmt` disponibile per la tua versione di Aurora PostgreSQL. Per ulteriori informazioni, consulta [Versioni dell’estensione Aurora PostgreSQL apg\$1plan\$1mgmt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) nelle *Note di rilascio per Aurora PostgreSQL*.
**Topics**
+ [Panoramica della gestione del piano di query per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md)
+ [Best practice per la gestione del piano di query Aurora PostgreSQL](AuroraPostgreSQL.Optimize.BestPractice.md)
+ [Gestione del piano di query di Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Start.md)
+ [Acquisizione dei piani di esecuzione Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md)
+ [Utilizzo dei piani gestiti per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md)
+ [Esame dei piani di query Aurora PostgreSQL nella vista dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md)
+ [Miglioramento dei piani di query di Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.md)
+ [Eliminazione dei piani di query di Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Deleting.md)
+ [Esportazione e importazione dei piani gestiti per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.ExportingImporting.md)
+ [Documentazione di riferimento dei parametri per la gestione del piano di query Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Parameters.md)
+ [Informazioni di riferimento sulle funzioni per la gestione del piano di query Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Functions.md)
+ [Riferimento per la visualizzazione apg\$1plan\$1mgmt.dba\$1plans per Aurora edizione compatibile con PostgreSQL](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md)
+ [Funzionalità avanzate della gestione del piano di query](AuroraPostgreSQL.QPM.Advanced.md)
# Panoramica della gestione del piano di query per Aurora PostgreSQL
La gestione del piano di query per Aurora PostgreSQL è progettata per garantire la stabilità del piano a prescindere dalle modifiche apportate al database che potrebbero causare la regressione del piano di query. La *regressione del piano di query* si verifica quando l'ottimizzatore sceglie un piano non ottimale per una determinata istruzione SQL dopo modifiche al sistema o al database. Le modifiche a statistiche, vincoli, impostazioni dell'ambiente, associazioni dei parametri di query e aggiornamenti al motore di database PostgreSQL possono tutte causare la regressione del piano.
La gestione del piano di query per Aurora PostgreSQLconsente di controllare come e quando cambiano i piani di esecuzione delle query. I vantaggi della gestione del piano di query per Aurora PostgreSQL includono i seguenti.
+ Migliorare la stabilità del piano forzando l'ottimizzatore a selezionare tra un numero ridotto di piani corretti.
+ Ottimizzare i piani centralmente e distribuire i migliori a livello globale.
+ Identificare gli indici non utilizzati e valutare l'impatto della creazione o della rimozione di un indice.
+ Rilevare automaticamente un nuovo piano a costo minimo individuato dall'ottimizzatore.
+ Provare nuove funzionalità dell'ottimizzatore con meno rischi, perché è possibile scegliere di approvare solo le modifiche dei piani che migliorano le performance.
Gli strumenti forniti dalla gestione del piano di query possono essere usati in modo proattivo per specificare il piano migliore per determinate query. In alternativa, è possibile utilizzare la gestione del piano di query per reagire a circostanze mutevoli ed evitare regressioni del piano. Per ulteriori informazioni, consulta [Best practice per la gestione del piano di query Aurora PostgreSQL](AuroraPostgreSQL.Optimize.BestPractice.md).
**Topics**
+ [Istruzioni SQL supportate](#AuroraPostgreSQL.Optimize.overview.features)
+ [Limitazioni della gestione del piano di query](#AuroraPostgreSQL.Optimize.overview.limitations)
+ [Terminologia della gestione del piano di query](#AuroraPostgreSQL.Optimize.Start-terminology)
+ [Versioni di gestione del piano di query per Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.overview.versions)
+ [Attivazione della gestione del piano di query per Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Enable)
+ [Aggiornamento della gestione del piano di query per Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Upgrade)
+ [Disattivazione della gestione del piano di query per Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Enable.turnoff)
## Istruzioni SQL supportate
La gestione del piano di query supporta i seguenti tipi di istruzioni SQL.
+ Qualsiasi istruzione SELECT, INSERT, UPDATE o DELETE, a prescindere dalla complessità.
+ Istruzioni preparate. Per ulteriori informazioni, consultare [PREPARE](https://www.postgresql.org/docs/14/sql-prepare.html) nella documentazione di PostgreSQL.
+ Istruzioni dinamiche, comprese quelle eseguite in modalità immediata. Per ulteriori informazioni, consultare [Dynamic SQL](https://www.postgresql.org/docs/current/ecpg-dynamic.html) ed [EXECUTE IMMEDIATE](https://www.postgresql.org/docs/current/ecpg-sql-execute-immediate.html) nella documentazione di PostgreSQL.
+ Comandi e istruzioni SQL incorporati. Per ulteriori informazioni, consultare [Embedded SQL Commands](https://www.postgresql.org/docs/current/ecpg-sql-commands.html) nella documentazione di PostgreSQL.
+ Istruzioni all'interno di funzioni denominate. Per ulteriori informazioni, consultare [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) nella documentazione di PostgreSQL.
+ Istruzioni contenenti tabelle temporanee.
+ Istruzioni all'interno di procedure e blocchi DO.
La gestione del piano di query può essere utilizzata con `EXPLAIN` in modalità manuale per acquisire un piano senza eseguirlo effettivamente. Per ulteriori informazioni, consulta [Analisi del piano scelto dall'ottimizzatore](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans). Per ulteriori informazioni sulle modalità di gestione del piano di query (manuale, automatica), consultare [Acquisizione dei piani di esecuzione Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
La gestione del piano di query PostgreSQL di Aurora supporta tutte le funzionalità del linguaggio PostgreSQL, tra cui tabelle partizionate, ereditarietà, sicurezza a livello di riga ed espressioni di tabella comuni ricorsive (). CTEs Per ulteriori informazioni su queste caratteristiche del linguaggio PostgreSQL, consultare [Table Partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html), [Row Security Policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) e [WITH Queries (Common Table Expressions)](https://www.postgresql.org/docs/current/queries-with.html) e altri argomenti nella documentazione di PostgreSQL.
Per informazioni sulle diverse versioni della funzionalità di gestione del piano di query di Aurora PostgreSQL, consulta [Versioni dell'estensione Aurora PostgreSQL apg\$1plan\$1mgmt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) nelle *Note di rilascio per Aurora PostgreSQL*.
## Limitazioni della gestione del piano di query
La versione corrente della gestione del piano di query di Aurora PostgreSQL include le seguenti limitazioni.
+ **I piani non vengono acquisiti per le istruzioni che fanno riferimento alle relazioni di sistema**: le istruzioni che fanno riferimento alle relazioni di sistema, ad esempio `pg_class`, non vengono acquisite. Si tratta di un'impostazione predefinita per evitare che venga acquisito un numero elevato di piani generati dal sistema utilizzati internamente. Questo vale anche per le tabelle di sistema all'interno delle viste.
+ **Potrebbe essere necessaria una classe di istanza DB più grande per il cluster DB Aurora PostgreSQL: a seconda del carico di lavoro, la gestione del piano di query potrebbe richiedere una classe di istanza** DB con più di 2 v. CPUs Il numero di `max_worker_processes` è limitato dalla dimensione della classe dell'istanza DB. Il numero di `max_worker_processes` forniti da una classe di istanza database con 2 vCPU (ad esempio db.t3.medium) può non essere sufficiente per un determinato carico di lavoro. Ti consigliamo di scegliere una classe di istanza DB con più di 2 v CPUs per il tuo cluster Aurora PostgreSQL DB se utilizzi la gestione del piano di query.
Se la classe di istanza database non è in grado di supportare il carico di lavoro, la gestione del piano di query genera un messaggio di errore come quello riportato di seguito.
```
WARNING: could not register plan insert background process
HINT: You may need to increase max_worker_processes.
```
In questo caso, è necessario aumentare il cluster database Aurora PostgreSQL fino a una dimensione della classe di istanza database con più memoria. Per ulteriori informazioni, consulta [Motori di database supportati per classi di istanza database](Concepts.DBInstanceClass.SupportAurora.md).
+ **I piani già archiviati nelle sessioni non vengono modificati**: la gestione dei piani di query fornisce un modo per influenzare i piani di query senza modificare il codice dell'applicazione. Tuttavia, quando un piano generico è già archiviato in una sessione esistente e se desideri modificarne il piano di query, devi prima impostare `plan_cache_mode` su `force_custom_plan` nel gruppo di parametri del cluster database.
+ `queryid` in `apg_plan_mgmt.dba_plans` e `pg_stat_statements` può essere diverso quando:
+ Gli oggetti vengono eliminati e ricreati dopo l'archiviazione in apg\$1plan\$1mgmt.dba\$1plans.
+ La tabella `apg_plan_mgmt.plans` viene importata da un altro cluster.
Per informazioni sulle diverse versioni della funzionalità di gestione del piano di query di Aurora PostgreSQL, consulta [Versioni dell'estensione Aurora PostgreSQL apg\$1plan\$1mgmt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) nelle *Note di rilascio per Aurora PostgreSQL*.
## Terminologia della gestione del piano di query
In questo argomento vengono utilizzati i seguenti termini.
**istruzione gestita**
Un'istruzione SQL acquisita dall'ottimizzatore durante la gestione del piano di query. Un'istruzione gestita ha uno o più piani di esecuzione della query archiviati nella vista `apg_plan_mgmt.dba_plans`.
**baseline del piano**
L'insieme di piani approvati per un'istruzione gestita specificata. Ovvero, tutti i piani per l'istruzione gestita che contengono "Approvato" per la relativa colonna `status` nella vista `dba_plan`.
**cronologia del piano**
L'insieme di tutti i piani acquisiti per un'istruzione gestita specificata. La cronologia del piano contiene tutti i piani acquisiti per l'istruzione, a prescindere dallo stato.
**regressione del piano di query**
Il caso in cui l'ottimizzatore sceglie un piano non ottimale rispetto a prima di una determinata modifica all'ambiente del database, ad esempio una nuova versione di PostgreSQL o modifiche alle statistiche.
## Versioni di gestione del piano di query per Aurora PostgreSQL
La gestione del piano di query è supportata da tutte le versioni di Aurora PostgreSQL attualmente disponibili. Per ulteriori informazioni, consultare l'elenco di [aggiornamenti di Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) nelle *Note di rilascio di Aurora PostgreSQL*.
La funzionalità di gestione del piano di query viene aggiunta al cluster database Aurora PostgreSQL quando si installa l'estensione `apg_plan_mgmt`. Versioni diverse di Aurora PostgreSQL supportano versioni differenti dell'estensione `apg_plan_mgmt`. Ti consigliamo di aggiornare l'estensione gestione del piano di query alla versione più recente per la versione di Aurora PostgreSQL.
**Nota**
Per le note di rilascio per ogni versione dell'estensione `apg_plan_mgmt`, consultare [Aurora PostgreSQL apg\$1plan\$1mgmt extension versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) nelle *Note di rilascio per Aurora PostgreSQL*.
È possibile identificare la versione in esecuzione sul cluster connettendosi a un'istanza mediante `psql` e utilizzando il metacomando \$1dx per elencare le estensioni come mostrato di seguito.
```
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)
```
L'output mostra che questo cluster utilizza la versione 1.0 dell'estensione. Solo alcune versioni di `apg_plan_mgmt` sono disponibili per una determinata versione di Aurora PostgreSQL. In alcuni casi, potrebbe essere necessario aggiornare il cluster database Aurora PostgreSQL a una nuova versione secondaria o applicare una patch in modo da poter eseguire l'aggiornamento alla versione più recente della gestione del piano di query. La `apg_plan_mgmt` versione 1.0 mostrata nell'output proviene da un cluster database Aurora PostgreSQL versione 10.17 che non dispone di una versione più recente di `apg_plan_mgmt` disponibile. In questo caso, il cluster database Aurora PostgreSQL deve essere aggiornato a una versione più recente di PostgreSQL.
Per ulteriori informazioni sull'aggiornamento di un cluster database Aurora PostgreSQL a una nuova versione di PostgreSQL, consultare [Aggiornamenti del motore di database Amazon Aurora PostgreSQL per 02/06/2020](AuroraPostgreSQL.Updates.md).
Per informazioni su come aggiornare l'estensione `apg_plan_mgmt`, consultare [Aggiornamento della gestione del piano di query per Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Upgrade).
## Attivazione della gestione del piano di query per Aurora PostgreSQL
La configurazione della gestione del piano di query per il cluster database Aurora PostgreSQL implica l'installazione di un'estensione e la modifica di diverse impostazioni dei parametri cluster database. Per installare l'estensione `apg_plan_mgmt` e attivare la funzionalità per il cluster database Aurora PostgreSQL sono necessarie autorizzazioni `rds_superuser`.
L'installazione dell'estensione crea un nuovo ruolo, `apg_plan_mgmt`, che consente agli utenti del database di visualizzare, gestire e mantenere i piani di query. In qualità di amministratore con privilegi `rds_superuser`, assicurati di concedere il ruolo `apg_plan_mgmt` agli utenti del database in base alle esigenze.
Solo gli utenti con il ruolo `rds_superuser` possono completare la procedura riportata di seguito. Il `rds_superuser` è necessario per creare l'estensione `apg_plan_mgmt` e il relativo ruolo `apg_plan_mgmt`. Il ruolo `apg_plan_mgmt` deve essere concesso agli utenti per gestire l'estensione `apg_plan_mgmt`.
**Come attivare la gestione del piano di query per il cluster database Aurora PostgreSQL**
I passaggi seguenti attivano la gestione del piano di query per tutte le istruzioni SQL che vengono inviate al cluster database Aurora PostgreSQL. Questa è nota come modalità *automatica*. Per ulteriori informazioni sulla differenza tra le modalità, consultare [Acquisizione dei piani di esecuzione Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegli un gruppo di parametri cluster di database personalizzato per il cluster database Aurora PostgreSQL. Per attivare la gestione del piano di query e impostare il suo comportamento, è necessario modificare determinati parametri. Per ulteriori informazioni, consulta [Creazione di un gruppo di parametri database in Amazon Aurora](USER_WorkingWithParamGroups.Creating.md).
1. Apri il gruppo di parametri cluster di database personalizzato e imposta il parametro `rds.enable_plan_management` su `1`, come mostrato nell'immagine seguente.
![\[Immagine del gruppo di parametri del cluster di database.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-qpm-custom-db-cluster-param-change-1.png)
Per ulteriori informazioni, consulta [Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Crea un gruppo di parametri database personalizzato che puoi utilizzare per impostare i parametri del piano di query a livello di istanza. Per ulteriori informazioni, consulta [Creazione di un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md).
1. Modifica l'istanza di scrittura del cluster database Aurora PostgreSQL per utilizzare il gruppo di parametri database personalizzato. Per ulteriori informazioni, consulta [Modifica di un'istanza database in un cluster database](Aurora.Modifying.md#Aurora.Modifying.Instance).
1. Modifica il cluster database Aurora PostgreSQL per utilizzare il gruppo di parametri database personalizzato. Per ulteriori informazioni, consulta [Modifica del cluster di database tramite la console, la CLI e l'API](Aurora.Modifying.md#Aurora.Modifying.Cluster).
1. Riavvia l'istanza database per abilitare le impostazioni del gruppo di parametri personalizzati.
1. Effettua la connessione all'endpoint dell'istanza database del cluster database Aurora PostgreSQL utilizzando `psql` o `pgAdmin`. L'esempio seguente utilizza l'account `postgres` predefinito per il ruolo `rds_superuser`.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=my-db
```
1. Crea l'estensione `apg_plan_mgmt` per l'istanza database, come mostrato di seguito.
```
labdb=> CREATE EXTENSION apg_plan_mgmt;
CREATE EXTENSION
```
**Suggerimento**
Installa l'estensione `apg_plan_mgmt` nel database modello per l'applicazione. Il database modello predefinito è denominato `template1`. Per ulteriori informazioni, consultare [Template Databases](https://www.postgresql.org/docs/current/manage-ag-templatedbs.html) nella documentazione di PostgreSQL.
1. Modifica il parametro `apg_plan_mgmt.capture_plan_baselines` in `automatic`. Questa impostazione consente all'ottimizzatore di generare i piani per ogni istruzione SQL pianificata o eseguita due o più volte.
**Nota**
La gestione del piano di Query dispone anche di una modalità *manuale* che è possibile utilizzare per istruzioni SQL specifiche. Per ulteriori informazioni, consulta [Acquisizione dei piani di esecuzione Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
1. Modifica il valore del parametro `apg_plan_mgmt.use_plan_baselines` in "on". Questo parametro consente all'ottimizzatore di scegliere un piano per l'istruzione dalla sua baseline del piano. Per ulteriori informazioni, consulta [Utilizzo dei piani gestiti per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md).
**Nota**
È possibile modificare il valore di uno di questi parametri dinamici per la sessione senza dover riavviare l'istanza.
Una volta completata la configurazione della gestione del piano di query, assicurati di concedere il ruolo `apg_plan_mgmt` a tutti gli utenti del database che devono visualizzare, gestire o mantenere piani di query.
## Aggiornamento della gestione del piano di query per Aurora PostgreSQL
Ti consigliamo di aggiornare l'estensione gestione del piano di query alla versione più recente per la versione di Aurora PostgreSQL.
1. Esegui la connessione all'istanza di scrittura del cluster database Aurora PostgreSQL come un utente che dispone di privilegi `rds_superuser`. Se hai mantenuto il nome predefinito durante la configurazione dell'istanza, esegui la connessione come `postgres`. In questo esempio viene illustrato come utilizzare `psql`, ma puoi anche utilizzare pgAdmin, se preferisci.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Esegui la seguente query per aggiornare l'estensione.
```
ALTER EXTENSION apg_plan_mgmt UPDATE TO '2.1';
```
1. Utilizza la funzione [apg\$1plan\$1mgmt.validate\$1plans](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.validate_plans) per aggiornare gli hash di tutti i piani. L'ottimizzatore convalida tutti i piani Approvato, Non approvato e Rifiutato per garantire che siano ancora piani validi per la nuova versione dell'estensione.
```
SELECT apg_plan_mgmt.validate_plans('update_plan_hash');
```
Per ulteriori informazioni sull'utilizzo di questa funzione, consultare [Convalida dei piani](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
1. Utilizza la funzione [apg\$1plan\$1mgmt.reload](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.reload) per aggiornare eventuali piani nella memoria condivisa con i piani convalidati dalla vista dba\$1plans.
```
SELECT apg_plan_mgmt.reload();
```
Per ulteriori informazioni su tutte le funzioni disponibili per la gestione del piano di query, consultare [Informazioni di riferimento sulle funzioni per la gestione del piano di query Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Functions.md).
## Disattivazione della gestione del piano di query per Aurora PostgreSQL
Puoi disabilitare la gestione del piano di query in qualsiasi momento disattivando `apg_plan_mgmt.use_plan_baselines` e `apg_plan_mgmt.capture_plan_baselines`:
```
labdb=> SET apg_plan_mgmt.use_plan_baselines = off;
labdb=> SET apg_plan_mgmt.capture_plan_baselines = off;
```
# Best practice per la gestione del piano di query Aurora PostgreSQL
La gestione del piano di query ti permette di controllare come e quando cambiano i piani di esecuzione delle query. In qualità di amministratore di database (DBA), gli obiettivi principali che desideri raggiungere utilizzando QPM sono prevenire le regressioni a seguito di modifiche al database e controllare quando l'ottimizzatore deve utilizzare un nuovo piano. Di seguito sono riportate alcune best practice consigliate su come utilizzare la gestione del piano di query. L'approccio di gestione del piano proattivo differisce da quello reattivo in termini di modalità e tempistiche dell'approvazione dei nuovi piani.
**Contents**
+ [Gestione del piano proattiva per prevenire la regressione delle prestazioni](#AuroraPostgreSQL.Optimize.BestPractice.Proactive)
+ [Garantire la stabilità del piano dopo un aggiornamento di versione principale](#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade)
+ [Gestione del piano reattiva per rilevare e correggere le regressioni delle prestazioni](#AuroraPostgreSQL.Optimize.BestPractice.Reactive)
## Gestione del piano proattiva per prevenire la regressione delle prestazioni
Per evitare che si verifichino regressioni delle prestazioni del piano, è possibile *far evolvere* le baseline del piano eseguendo una procedura che confronta le prestazioni dei piani appena individuati con le prestazioni della baseline esistente dei piani approvati e quindi approva automaticamente il set di piani più rapido come nuova baseline. In questo modo, la baseline dei piani migliora nel tempo man mano che vengono individuati i piani più rapidi.
1. In un ambiente di sviluppo, identificare le istruzioni SQL che hanno il maggiore impatto sulle prestazioni o sulla velocità effettiva del sistema. Quindi acquisire i piani per queste dichiarazioni come descritto in [Acquisizione manuale dei piani per specifiche istruzioni SQL](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Manual) e [Acquisizione automatica dei piani](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Esportare i piani acquisiti dall'ambiente di sviluppo e importarli nell'ambiente di produzione. Per ulteriori informazioni, consulta [Esportazione e importazione dei piani gestiti per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.ExportingImporting.md).
1. In produzione, eseguire l'applicazione e applicare l'utilizzo di piani gestiti approvati. Per ulteriori informazioni, consulta [Utilizzo dei piani gestiti per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md). Durante l'esecuzione dell'applicazione, aggiungere nuovi piani quando l'ottimizzatore li rileva. Per ulteriori informazioni, consulta [Acquisizione automatica dei piani](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Analizzare i piani non approvati e approvare quelli che funzionano bene. Per ulteriori informazioni, consulta [Valutazione delle prestazioni del piano](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
1. Mentre l'applicazione continua a essere eseguita, l'ottimizzatore inizia a usare i nuovi piani secondo le necessità.
### Garantire la stabilità del piano dopo un aggiornamento di versione principale
Ogni versione principale di PostgreSQL include miglioramenti e modifiche all'ottimizzatore di query progettati per potenziare le prestazioni. Tuttavia, i piani di esecuzione delle query generati dal servizio di ottimizzazione nelle versioni precedenti potrebbero causare regressioni delle prestazioni nelle versioni aggiornate più recenti. È possibile utilizzare la gestione del piano di query per risolvere i problemi di prestazione e garantire la stabilità del piano dopo un aggiornamento della versione principale.
L'ottimizzatore utilizza sempre il piano di costo minimo approvato, anche se esistono più piani approvati per la stessa istruzione. Dopo un aggiornamento, l'ottimizzatore potrebbe scoprire nuovi piani, ma questi verranno salvati come piani non approvati. Questi piani vengono eseguiti solo se approvati utilizzando lo stile reattivo di gestione del piano con il parametro unapproved\$1plan\$1execution\$1threshold. È possibile massimizzare la stabilità del piano utilizzando lo stile proattivo di gestione del piano con il parametro evolve\$1plan\$1baselines. In questo modo si confrontano le prestazioni dei nuovi piani con quelle dei vecchi piani e si approvano o rifiutano i piani che sono almeno il 10% più veloci rispetto al piano migliore successivo.
Dopo l'aggiornamento, utilizza la funzione `evolve_plan_baselines` con le associazioni dei parametri di query per confrontare le prestazioni del piano prima e dopo l'aggiornamento. I seguenti passaggi presuppongono che tu abbia utilizzato piani gestiti approvati nel tuo ambiente di produzione, come descritto in [Utilizzo dei piani gestiti per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md).
1. Prima di procedere con l'aggiornamento, esegui l'applicazione e assicurati che il gestore del piano di query sia in esecuzione. Mentre l'applicazione è in esecuzione, aggiungi i nuovi piani rilevati dall'ottimizzatore. Per ulteriori informazioni, consulta [Acquisizione automatica dei piani](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Valuta le prestazioni di ciascun piano. Per ulteriori informazioni, consulta [Valutazione delle prestazioni del piano](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
1. Dopo l'aggiornamento, analizza di nuovo i piani approvati utilizzando la funzione `evolve_plan_baselines`. Confronta le prestazioni prima e dopo l'utilizzo delle associazioni dei parametri di query. Se il nuovo piano è veloce, aggiungilo all'elenco dei piani approvati. Se è più veloce di un altro piano in base alle stesse associazioni di parametri, è possibile contrassegnare il piano più lento come Rejected (Rifiutato).
Per ulteriori informazioni, consulta [Approvazione dei piani migliori](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance.Approving). Per ulteriori informazioni su questa funzione, consulta [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines).
Per ulteriori informazioni, consulta [Garantire prestazioni coerenti dopo gli aggiornamenti delle versioni principali con la gestione del piano di query di Amazon Aurora edizione compatibile con PostgreSQL](https://aws.amazon.com/blogs/database/ensuring-consistent-performance-after-major-version-upgrades-with-amazon-aurora-postgresql-query-plan-management/).
**Nota**
Quando esegui un aggiornamento di una versione principale utilizzando la replica logica di AWS DMS, assicurati di replicare lo schema `apg_plan_mgmt` per garantire che i piani esistenti vengano copiati nell'istanza aggiornata. Per ulteriori informazioni sulla replica logica, consulta [Utilizzo della replica logica per eseguire l'aggiornamento a una versione principale per Aurora PostgreSQL](AuroraPostgreSQL.MajorVersionUpgrade.md).
## Gestione del piano reattiva per rilevare e correggere le regressioni delle prestazioni
Rileva quali piani causano regressioni delle prestazioni monitorando l'applicazione mentre è in esecuzione. Quando rilevi regressioni, rifiuta o correggi manualmente i piani inefficienti seguendo questi passaggi:
1. Durante l'esecuzione dell'applicazione, applica l'uso dei piani gestiti e aggiungi automaticamente i piani appena rilevati come non approvati. Per ulteriori informazioni, consulta [Utilizzo dei piani gestiti per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md) e [Acquisizione automatica dei piani](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Monitorare l'applicazione in esecuzione per le regressioni delle prestazioni.
1. Quando viene rilevata una regressione del piano, impostare lo stato del piano su `rejected`. La volta successiva che l'ottimizzatore esegue l'istruzione SQL, ignora automaticamente il piano rifiutato e utilizza invece un piano approvato diverso. Per ulteriori informazioni, consulta [Rifiuto o disabilitazione dei piani più lenti](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance.Rejecting).
In alcuni casi, si potrebbe preferire correggere un piano danneggiato piuttosto che rifiutarlo, disabilitarlo o cancellarlo. Usare l'estensione `pg_hint_plan` per sperimentare il miglioramento di un piano. Con `pg_hint_plan`, si usano commenti speciali per indicare all'ottimizzatore di ignorare il modo in cui normalmente crea un piano. Per ulteriori informazioni, consulta [Correzione dei piani mediante pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan).
# Gestione del piano di query di Aurora PostgreSQL
Con la gestione del piano di query attivata per il cluster database Aurora PostgreSQL, l'ottimizzatore genera e archivia i piani di esecuzione delle query per qualsiasi istruzione SQL che viene elaborata più di una volta. L'ottimizzatore imposta sempre lo stato del primo piano generato dell'istruzione gestita su `dba_plans` e lo archivia nella vista `Approved`.
Il set di piani approvati salvati per un'istruzione gestita è noto come *baseline del piano*. Mentre l'applicazione è in corso, l'ottimizzatore potrebbe generare piani aggiuntivi per le istruzioni gestite. L'ottimizzatore imposta i piani acquisiti aggiuntivi su uno stato di `Unapproved`.
In seguito, si può decidere se i piani `Unapproved` vengono eseguiti correttamente e cambiarli in `Approved`, `Rejected` o `Preferred`. A tale scopo, si utilizza la funzione `apg_plan_mgmt.evolve_plan_baselines` o la funzione `apg_plan_mgmt.set_plan_status`.
Quando l'ottimizzatore genera un piano per un'istruzione SQL, la gestione del piano di query salva il piano nella tabella `apg_plan_mgmt.plans`. Gli utenti del database cui è stato concesso il ruolo `apg_plan_mgmt` possono visualizzare i dettagli del piano eseguendo una query sulla vista `apg_plan_mgmt.dba_plans`. Ad esempio, nella seguente query vengono elencati i dettagli dei piani attualmente nella vista per un cluster database Aurora PostgreSQL non di produzione.
+ `sql_hash`: un identificatore per l'istruzione SQL che è il valore hash per il testo normalizzato dell'istruzione SQL.
+ `plan_hash`: un identificatore univoco per il piano che è una combinazione di `sql_hash` e di un hash del piano.
+ `status`: lo stato del piano. L'ottimizzatore può eseguire un piano approvato.
+ `enabled`: indica se il piano è pronto per l'uso (true) o no (false).
+ `plan_outline`: una rappresentazione del piano che viene utilizzata per ricreare il piano di esecuzione effettivo. Gli operatori nella struttura ad albero vengono mappati agli operatori nell'output EXPLAIN.
La vista `apg_plan_mgmt.dba_plans` contiene molte altre colonne contenenti tutti i dettagli del piano, ad esempio la data dell'ultimo utilizzo del piano. Per tutti i dettagli completi, consultare [Riferimento per la visualizzazione apg\$1plan\$1mgmt.dba\$1plans per Aurora edizione compatibile con PostgreSQL](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md).
## Normalizzazione e l'hash SQL
Nella vista `apg_plan_mgmt.dba_plans`, è possibile identificare un'istruzione gestita in base al suo valore hash SQL. L'hash SQL viene calcolato su una rappresentazione normalizzata dell'istruzione SQL che rimuove alcune differenze, ad esempio i valori letterali.
Il processo di *normalizzazione* per ogni istruzione SQL consente di conservare spazio e maiuscole/minuscole, in modo da poter leggere e comprendere l'essenza dell'istruzione SQL. La normalizzazione rimuove o sostituisce i seguenti elementi.
+ Commenti di blocco iniziali
+ La parola chiave EXPLAIN e le opzioni EXPLAIN ed EXPLAIN ANALYZE
+ Spazi finali
+ Tutti i letterali
Ad esempio, considerare la seguente istruzione.
```
/*Leading comment*/ EXPLAIN SELECT /* Query 1 */ * FROM t WHERE x > 7 AND y = 1;
```
La gestione del piano di query normalizza questa istruzione come mostrato:
```
SELECT /* Query 1 */ * FROM t WHERE x > CONST AND y = CONST;
```
La normalizzazione consente di utilizzare lo stesso hash SQL per istruzioni SQL simili che potrebbero differire solo nei loro valori letterali o dei parametri. In altre parole, possono esistere più piani per lo stesso hash SQL, con un piano diverso ottimale in condizioni diverse.
**Nota**
Una singola istruzione SQL utilizzata con schemi diversi dispone di piani diversi perché è associata allo schema specifico in fase di runtime. Il planner utilizza le statistiche per l'associazione dello schema per scegliere il piano ottimale.
Per ulteriori informazioni su come l'ottimizzatore sceglie un piano, consultare [Utilizzo dei piani gestiti per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md). In questa sezione vengono fornite informazioni su come utilizzare `EXPLAIN` e `EXPLAIN ANALYZE` per visualizzare l'anteprima di un piano prima che venga effettivamente utilizzato. Per informazioni dettagliate, vedi [Analisi del piano scelto dall'ottimizzatore](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans). Per un'immagine che illustra il processo di scelta di un piano, consultare [In che modo l'ottimizzatore sceglie quale piano eseguire.](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans).
# Acquisizione dei piani di esecuzione Aurora PostgreSQL
La gestione del piano di query di Aurora PostgreSQL offre due diverse modalità di acquisizione dei piani di esecuzione delle query: automatica o manuale. La modalità viene scelta impostando il valore di `apg_plan_mgmt.capture_plans_baselines` su `automatic` o su `manual`. Puoi acquisire i piani di esecuzione per specifiche istruzioni SQL utilizzando l'acquisizione manuale del piano. In alternativa, puoi acquisire tutti i piani (o quelli più lenti) che vengono eseguiti due o più volte durante l'esecuzione dell'applicazione utilizzando l'acquisizione automatica del piano.
Durante l'acquisizione dei piani, l'ottimizzatore imposta lo stato del primo piano acquisito dell'istruzione gestita su `approved`. L'ottimizzatore imposta lo stato di qualsiasi altro piano acquisito per un'istruzione gestita su `unapproved`. Tuttavia, a volte, più di un piano potrebbe essere salvato con lo stato `approved`. Ciò può accadere quando vengono creati più piani per un'istruzione in parallelo e prima che venga eseguito il commit del primo piano per l'istruzione.
Per controllare il numero massimo di piani che possono essere acquisiti e archiviati nella visualizzazione `dba_plans`, imposta il parametro `apg_plan_mgmt.max_plans` nel gruppo di parametri a livello di istanza database. La modifica del parametro `apg_plan_mgmt.max_plans` richiede il riavvio dell'istanza database per rendere effettivo il nuovo valore. Per ulteriori informazioni, vedi il parametro [apg\$1plan\$1mgmt.max\$1plans](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.max_plans).
## Acquisizione manuale dei piani per specifiche istruzioni SQL
Se hai un set di istruzioni SQL da gestire, inserisci le istruzioni in un file script SQL e quindi acquisisci manualmente i piani. Di seguito è riportato un esempio di psql per acquisire manualmente i piani di query per un set di istruzioni SQL.
```
psql> SET apg_plan_mgmt.capture_plan_baselines = manual;
psql> \i my-statements.sql
psql> SET apg_plan_mgmt.capture_plan_baselines = off;
```
Dopo aver acquisito un piano per ogni istruzione SQL, l'ottimizzatore aggiunge una nuova riga alla visualizzazione `apg_plan_mgmt.dba_plans`.
Ti consigliamo di utilizzare le istruzioni EXPLAIN o EXPLUTE EXPLAIN nel file di script SQL. Assicurati di includere abbastanza variazioni nei valori dei parametri per acquisire tutti i piani di interesse.
Se conosci un piano migliore del piano a costo minimo dell'ottimizzatore, puoi forzare l'ottimizzatore a utilizzare il piano migliore. Per farlo, specifica uno o più hint dell'ottimizzatore. Per ulteriori informazioni, consulta [Correzione dei piani mediante pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). Per confrontare le prestazioni dei piani `unapproved` e `approved` e approvarli, rifiutarli o eliminarli, consulta [Valutazione delle prestazioni del piano](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
## Acquisizione automatica dei piani
Utilizza l'acquisizione automatica dei piani per situazioni come le seguenti:
+ Non conosci le istruzioni SQL specifiche da gestire.
+ Hai centinaia o migliaia di istruzioni SQL da gestire.
+ L'applicazione utilizza un'API client. Ad esempio, JDBC utilizza le istruzioni preparate senza nome o le istruzioni in modalità bulk che non possono essere espresse in psql.
**Per acquisire i piani automaticamente**
1. Attivare l'acquisizione automatica dei piani impostando `apg_plan_mgmt.capture_plan_baselines` su `automatic` nel gruppo di parametri a livello di istanza database. Per ulteriori informazioni, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
1. Durante l'esecuzione dell'applicazione, l'ottimizzatore acquisisce i piani per ogni istruzione SQL eseguita almeno due volte.
Durante l'esecuzione dell'applicazione con le impostazioni predefinite dei parametri della gestione del piano di query, l'ottimizzatore acquisisce i piani per ogni istruzione SQL eseguita almeno due volte. L'acquisizione di tutti i piani mentre si utilizzano i valori predefiniti ha un overhead di runtime molto ridotto e può essere abilitato in produzione.
**Per disattivare l'acquisizione automatica dei piani**
+ Impostare il parametro `apg_plan_mgmt.capture_plan_baselines` su `off` nel gruppo di parametri a livello di istanza database.
Per misurare le prestazioni dei piani non approvati e approvarli, rifiutarli o eliminarli, consulta [Valutazione delle prestazioni del piano](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
# Utilizzo dei piani gestiti per Aurora PostgreSQL
Per fare in modo che l'ottimizzatore utilizzi i piani acquisiti per le istruzioni gestite, imposta il parametro `apg_plan_mgmt.use_plan_baselines` su `true`. Di seguito è riportato un esempio di istanza locale.
```
SET apg_plan_mgmt.use_plan_baselines = true;
```
Durante l'esecuzione dell'applicazione, questa impostazione fa in modo che l'ottimizzatore utilizzi il piano a costo minimo, preferito o approvato, valido e abilitato per ciascuna istruzione gestita.
## Analisi del piano scelto dall'ottimizzatore
Quando il parametro `apg_plan_mgmt.use_plan_baselines` è impostato su `true`, puoi utilizzare le istruzioni SQL EXPLAIN ANALYZE per far sì che l'ottimizzatore mostri il piano che userebbe se dovesse eseguire l'istruzione . Di seguito è riportato un esempio di :
```
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
```
L'output mostra il piano Approvato dalla baseline che viene eseguita. Tuttavia, l'output mostra anche che è stato trovato un piano a costo inferiore. In questo caso, acquisisci questo nuovo piano a costo minimo attivando l'acquisizione automatica del piano come descritto in [Acquisizione automatica dei piani](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
I nuovi piani vengono sempre acquisiti dall'ottimizzatore come `Unapproved`. Utilizza la funzione `apg_plan_mgmt.evolve_plan_baselines` per confrontare i piani e cambiarli in approvati, rifiutati o disabilitati. Per ulteriori informazioni, consulta [Valutazione delle prestazioni del piano](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
## In che modo l'ottimizzatore sceglie quale piano eseguire.
Il costo di un piano di esecuzione è una stima valutata dall'ottimizzatore per confrontare diversi piani. Nel calcolo del costo di un piano, l'ottimizzatore include fattori come la CPU e I/O le operazioni richieste da quel piano. Per ulteriori informazioni sui costi del pianificatore query PostgreSQL, consulta [Query Planning](https://www.postgresql.org/docs/current/runtime-config-query.html) nella documentazione di PostgreSQL.
Nella seguente immagine viene illustrata la modalità di scelta di un piano per una determinata istruzione SQL, a seconda che la gestione del piano di query sia attiva o non attiva.
![\[Flusso di lavoro della gestione del piano di query per Aurora PostgreSQL\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-query-plan-mgmt_processing-flow.png)
Di seguito è riportato il flusso:
1. L'ottimizzatore genera un piano a costo minimo per l'istruzione SQL.
1. Se la gestione del piano di query non è attiva, il piano dell'ottimizzatore viene eseguito immediatamente (A. Run Optimizer's plan). La gestione del piano di query è inattiva quando si utilizzano le impostazioni predefinite dei parametri `apg_plan_mgmt.capture_plan_baselines` e `apg_plan_mgmt.use_plan_baselines` (rispettivamente "off" e "false").
In caso contrario, la gestione del piano di query è attiva. In questo caso, l'istruzione SQL e il relativo piano dell'ottimizzatore vengono ulteriormente valutati prima che venga scelto un piano.
**Suggerimento**
Utenti del database con il ruolo `apg_plan_mgmt` possono confrontare in maniera proattiva i piani, modificare lo stato dei piani e imporre l'uso di piani specifici, in base alle esigenze. Per ulteriori informazioni, consulta [Miglioramento dei piani di query di Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.md).
1. È possibile che l'istruzione SQL disponga già di piani archiviati da gestione dei piani di query in passato. I piani sono archiviati in `apg_plan_mgmt.dba_plans`, insieme alle informazioni relative alle istruzioni SQL utilizzate per crearli. Le informazioni relative a un piano includono il suo stato. Lo stato di un piano può determinare se è utilizzato o meno, come descritto di seguito.
1. Se il piano non è incluso tra i piani archiviati per l'istruzione SQL, significa che è la prima volta che questo particolare piano è stato generato dall'ottimizzatore per l'istruzione SQL specificata. Il piano viene inviato all’elaborazione del piano di acquisizione (4).
1. Se il piano è incluso tra i piani archiviati e il suo stato è Approvato o Preferito, il piano viene eseguito (A. Run Optimizer's plan).
Se il piano è incluso tra i piani archiviati ma non è né Approvato né Preferito, viene inviato all’elaborazione del piano di acquisizione (4).
1. Quando un piano viene acquisito per la prima volta per una determinata istruzione SQL, il suo stato è sempre impostato su Approvato (P1). Se l'ottimizzatore genera successivamente lo stesso piano per la stessa istruzione SQL, lo stato viene modificato in Non approvato (p1\$1n).
Con il piano di acquisito e il relativo stato aggiornato, la valutazione continua nel passaggio successivo (5).
1. La *linea di base* di un piano è costituita dalla cronologia dell'istruzione SQL e dei relativi piani in vari stati. La gestione del piano di query può tenere conto della linea di base durante la scelta di un piano, a seconda che l'opzione Use plan baselines (Usa linee di base del piano) sia attivata o meno, come illustrato di seguito.
+ L’opzione Use plan baselines (Usa linee di base del piano) è "disattivata" quando il parametro `apg_plan_mgmt.use_plan_baselines` è impostato sul suo valore predefinito (`false`). Il piano non viene confrontato con la linea di base prima di essere eseguito (A. Run Optimizer's plan).
+ L’opzione Use plan baselines (Usa linee di base del piano) è "attivata" quando il parametro `apg_plan_mgmt.use_plan_baselines` è impostato su `true`. Il piano viene ulteriormente valutato utilizzando la linea di base (6).
1. Il piano viene confrontato ad altri piani per l’istruzione nella linea di base.
1. Se il piano dell'ottimizzatore è incluso tra i piani della linea di base, il suo stato viene controllato (7a).
1. Se il piano dell'ottimizzatore non è incluso tra i piani della linea di base, viene aggiunto ai piani per l’istruzione come un nuovo piano `Unapproved`.
1. Lo stato del piano viene controllato per determinare solo se è Non è approvato.
1. Se lo stato del piano è Non approvato, il costo stimato del piano viene confrontato alla stima dei costi specificata per la soglia del piano di esecuzione non approvato.
+ Se il costo stimato del piano è inferiore alla soglia, l'ottimizzatore lo utilizza anche se è Non approvato (A. Run Optimizer's plan). In genere, l'ottimizzatore non esegue un piano Non approvato. Tuttavia, quando il parametro `apg_plan_mgmt.unapproved_plan_execution_threshold` specifica un valore di soglia di costo, l'ottimizzatore confronta il costo del piano Non approvato alla soglia. Se il costo stimato è inferiore alla soglia, l'ottimizzatore esegue il piano. Per ulteriori informazioni, consulta [apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.unapproved_plan_execution_threshold).
+ Se il costo stimato del piano non è inferiore alla soglia, vengono controllati gli altri attributi del piano (8a).
1. Se lo stato del piano è diverso da Non approvato, vengono controllati i suoi altri attributi (8a).
1. L’ottimizzatore non utilizzerà un piano che è disabilitato. Ovvero, il piano il cui attributo `enable` è impostato su 'f' (falso). Inoltre, l'ottimizzatore non utilizzerà un piano il cui stato è Rifiutato.
L'ottimizzatore non può utilizzare piani non validi. I piani possono diventare non validi nel tempo quando gli oggetti da cui dipendono, ad esempio indici e partizioni di tabella, vengono rimossi o eliminati.
1. Se l'istruzione dispone di piani preferiti abilitati e validi, l'ottimizzatore sceglie il piano a costo minimo tra i piani preferiti archiviati per l'istruzione SQL. L'ottimizzatore quindi esegue il piano preferito a costo minimo.
1. Se l’istruzione non dispone di piani preferiti abilitati e validi, viene valutata nel passaggio successivo (9).
1. Se l'istruzione dispone di piani approvati abilitati e validi, l'ottimizzatore sceglie il piano a costo minimo tra i piani approvati archiviati per l'istruzione SQL. L'ottimizzatore quindi esegue il piano approvato a costo minimo.
Se l’istruzione non dispone di piani approvati validi e abilitati, l'ottimizzatore utilizza il piano a costo minimo (A. Run Optimizer's plan).
# Esame dei piani di query Aurora PostgreSQL nella vista dba\$1plans
Gli utenti e gli amministratori del database cui è stato concesso il ruolo `apg_plan_mgmt` possono visualizzare e gestire i piani archiviati in `apg_plan_mgmt.dba_plans`. Un amministratore di un cluster database Aurora PostgreSQL (un utente con autorizzazioni `rds_superuser`) deve concedere esplicitamente questo ruolo agli utenti del database che devono utilizzare la gestione del piano di query.
La vista `apg_plan_mgmt` contiene la cronologia del piano per tutte le istruzioni SQL gestite per ogni database sull'istanza di scrittura del cluster database Aurora PostgreSQL. Questa vista consente di esaminare i piani, il relativo stato, la data di ultimo utilizzo e tutti gli altri dettagli pertinenti.
Come discusso in [Normalizzazione e l'hash SQL](AuroraPostgreSQL.Optimize.Start.md#AuroraPostgreSQL.Optimize.Start.hash-and-normalization), ogni piano gestito è identificato dalla combinazione di un valore hash SQL e un valore hash del piano. Con questi identificatori, puoi usare strumenti come Amazon RDS Performance Insights per tenere traccia delle prestazioni del singolo piano. Per ulteriori informazioni su Performance Insights, consulta [Utilizzo di Amazon RDS Performance Insights]( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
## Elenco dei piani gestiti.
Per elencare i piani gestiti, utilizza un'istruzione SELECT sulla visualizzazione `apg_plan_mgmt.dba_plans`. L'esempio seguente mostra alcune colonne nella visualizzazione `dba_plans`, come la colonna `status` che identifica i piani approvati e non approvati.
```
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)
```
Per una migliore leggibilità, la query e l'output mostrati elencano solo alcune delle colonne della vista `dba_plans`. Per informazioni complete, consultare [Riferimento per la visualizzazione apg\$1plan\$1mgmt.dba\$1plans per Aurora edizione compatibile con PostgreSQL](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md).
# Miglioramento dei piani di query di Aurora PostgreSQL
Migliora la gestione del piano di interrogazione valutando le prestazioni del piano e correggendo i piani. Per ulteriori informazioni sul miglioramento dei piani di query, consulta gli argomenti seguenti.
**Topics**
+ [Valutazione delle prestazioni del piano](#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance)
+ [Correzione dei piani mediante pg\$1hint\$1plan](#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan)
## Valutazione delle prestazioni del piano
Dopo che l'ottimizzatore acquisisce i piani come non approvati, utilizza la funzione `apg_plan_mgmt.evolve_plan_baselines` per confrontare i piani in base alle prestazioni effettive. A seconda dell'esito degli esperimenti sulle prestazioni, puoi modificare lo stato di un piano da non approvato ad approvato o rifiutato. Puoi invece decidere di utilizzare la funzione `apg_plan_mgmt.evolve_plan_baselines` per disabilitare temporaneamente un piano se non soddisfa i requisiti.
### Approvazione dei piani migliori
Nell'esempio seguente viene illustrato come modificare lo stato dei piani gestiti per l'approvazione utilizzando la funzione `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)
```
L'output mostra un rapporto delle prestazioni per l'istruzione `rangequery` con i binding di parametri 1 e 10.000. Il nuovo piano non approvato (`Baseline+1`) è migliore del piano migliore approvato in precedenza (`Baseline`). Per confermare che il nuovo piano è ora `Approved`, controlla la visualizzazione `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)
```
Il piano gestito ora include due piani approvati che rappresentano la baseline del piano dell'istruzione. Puoi anche chiamare la funzione `apg_plan_mgmt.set_plan_status` per impostare direttamente il campo di stato di un piano su `'Approved'`, `'Rejected'`, `'Unapproved'` o `'Preferred'`.
### Rifiuto o disabilitazione dei piani più lenti
Per rifiutare o disabilitare i piani, passa `'reject'` o `'disable' `come parametro di operazione alla funzione `apg_plan_mgmt.evolve_plan_baselines`. Questo esempio disabilita qualsiasi piano `Unapproved` acquisito che è più lento per almeno il 10 percento del miglior piano `Approved` per l'istruzione.
```
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
```
Puoi anche impostare direttamente un piano su rifiutato o disabilitato. Per impostare direttamente il campo abilitato di un piano su `true` o `false`, chiama la funzione `apg_plan_mgmt.set_plan_enabled`. Per impostare direttamente il campo di stato di un piano su `'Approved'`, `'Rejected'`, `'Unapproved'` o `'Preferred'`, chiama la funzione `apg_plan_mgmt.set_plan_status`.
Per eliminare i piani non validi e che si prevede rimangano non validi, utilizza la funzione `apg_plan_mgmt.validate_plans`. Questa funzione consente di eliminare o disabilitare i piani non validi. Per ulteriori informazioni, consulta [Convalida dei piani](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
## Correzione dei piani mediante pg\$1hint\$1plan
L'ottimizzatore di query è progettato per trovare un piano ottimale per tutte le istruzioni e nella maggior parte dei casi trova un buon piano. Tuttavia, occasionalmente potresti realizzare che esiste un piano molto migliore di quello generato dall'ottimizzatore. Due modi consigliati per ottenere che l'ottimizzatore generi un piano desiderato sono l'uso dell'estensione `pg_hint_plan` o l'impostazione delle variabili GUC (Grand Unified Configuration) in PostgreSQL:
+ Estensione `pg_hint_plan` – Specifica un "hint" per modificare il funzionamento del pianificatore utilizzando l'estensione `pg_hint_plan` di PostgreSQL. Per installare e ottenere ulteriori informazioni su come utilizzare l'estensione `pg_hint_plan`, consulta la [documentazione di pg\$1hint\$1plan](https://github.com/ossc-db/pg_hint_plan).
+ Variabili GUC – Sostituisci uno o più parametri del modello di costo o altri parametri dell'ottimizzatore, come ad esempio `from_collapse_limit` o `GEQO_threshold`.
Quando utilizzi una di queste tecniche per imporre all'ottimizzatore di query di utilizzare un piano, puoi utilizzare anche la gestione del piano di query per acquisire e imporre l'utilizzo del nuovo piano.
È possibile utilizzare l'estensione `pg_hint_plan` per modificare l'ordine di join, i metodi di join oi percorsi di accesso per un'istruzione SQL. Utilizza un commento SQL con la speciale sintassi `pg_hint_plan` per modificare il modo in cui l'ottimizzatore crea un piano. Ad esempio, supponiamo che l'istruzione SQL del problema abbia un join bidirezionale.
```
SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Quindi, supponiamo che l'ottimizzatore scelga l'ordine di join (t1, t2), ma si sa che l'ordine di join (t2, t1) è più veloce. Il seguente hint forza l'ottimizzatore a utilizzare l'ordine di join più veloce, (t2, t1). Includi EXPLAIN in modo che l'ottimizzatore generi un piano per l'istruzione SQL ma senza eseguire l'istruzione (output non mostrato).
```
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
I passaggi seguenti illustrano come utilizzare `pg_hint_plan`.
**Per modificare il piano generato dall'ottimizzatore e acquisire il piano utilizzando pg\$1hint\$1plan**
1. Attivare la modalità di acquisizione manuale.
```
SET apg_plan_mgmt.capture_plan_baselines = manual;
```
1. Specificare un hint per l'istruzione SQL desiderata.
```
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Al termine dell'esecuzione, l'ottimizzatore acquisisce il piano nella visualizzazione `apg_plan_mgmt.dba_plans`. Il piano acquisito non include la speciale sintassi dei commenti `pg_hint_plan` perché la gestione del piano di query normalizza l'istruzione rimuovendo i commenti iniziali.
1. Visualizzare i piani gestiti utilizzando la visualizzazione `apg_plan_mgmt.dba_plans`.
```
SELECT sql_hash, plan_hash, status, sql_text, plan_outline
FROM apg_plan_mgmt.dba_plans;
```
1. Impostare lo stato del piano su `Preferred`. In questo modo si assicura che l'ottimizzatore scelga di eseguirlo invece di selezionare un piano dall'insieme dei piani approvati quando il piano a costo minimo non è già `Approved` o `Preferred`.
```
SELECT apg_plan_mgmt.set_plan_status(sql-hash, plan-hash, 'preferred' );
```
1. Disattivare l'acquisizione del piano manuale e applicare l'utilizzo dei piani gestiti.
```
SET apg_plan_mgmt.capture_plan_baselines = false;
SET apg_plan_mgmt.use_plan_baselines = true;
```
Ora, quando viene eseguita l'istruzione SQL originale, l'ottimizzatore sceglierà un piano `Approved` o `Preferred`. Se il piano a costo minimo non è `Approved` o `Preferred`, l'ottimizzatore sceglierà il piano `Preferred`.
# Eliminazione dei piani di query di Aurora PostgreSQL
Eliminare i piani di esecuzione non utilizzati o i piani non validi. Per ulteriori informazioni sull’eliminazione dei piani, consultare le sezioni successive.
**Topics**
+ [Eliminazione dei piani](#AuroraPostgreSQL.Optimize.Maintenance.DeletingPlans)
+ [Convalida dei piani](#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans)
## Eliminazione dei piani
I piani vengono eliminati automaticamente se non vengono utilizzati da più di un mese, specificatamente, 32 giorni. Questa è l'impostazione di default per il parametro `apg_plan_mgmt.plan_retention_period`. È possibile modificare il periodo di conservazione del piano in un periodo di tempo più lungo o più breve a partire dal valore di 1. La determinazione del numero di giorni dall'ultimo utilizzo di un piano viene calcolata sottraendo la data `last_used` dalla data corrente. La data `last_used` si riferisce alla data più recente in cui l'ottimizzatore ha scelto un piano come il piano di costo minimo o alla data di esecuzione del piano. La data viene archiviata per il piano nella vista `apg_plan_mgmt.dba_plans`.
Ti consigliamo di eliminare i piani che non sono stati utilizzati per molto tempo o che non sono utili. Ad ogni piano è assegnata una data `last_used` che viene aggiornata dall'ottimizzatore ogni volta che esegue il piano o che sceglie il piano come il piano a costo minimo per un'istruzione. Controlla le date `last_used` più recenti per identificare i piani che è possibile eliminare in modo sicuro.
La seguente query restituisce una tabella a tre colonne con il numero totale di piani, i piani che non sono stati eliminati e i piani eliminati con successo. Include una query annidata che è un esempio di utilizzo della funzione `apg_plan_mgmt.delete_plan` per eliminare tutti i piani che non sono stati scelti come il piano a costo minimo negli ultimi 31 giorni e il cui stato non è `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
```
Per ulteriori informazioni, consulta [apg\$1plan\$1mgmt.delete\$1plan](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.delete_plan).
Per eliminare i piani non validi e che si prevede rimangano non validi, utilizza la funzione `apg_plan_mgmt.validate_plans`. Questa funzione consente di eliminare o disabilitare i piani non validi. Per ulteriori informazioni, consulta [Convalida dei piani](#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
**Importante**
Se i piani estranei non vengono eliminati, esiste il rischio di esaurimento della memoria condivisa dedicata alla gestione del piano di query. Per controllare la quantità di memoria disponibile per i piani gestiti, utilizzare il parametro `apg_plan_mgmt.max_plans`. Impostare questo parametro nel gruppo di parametri database personalizzati e riavviare l'istanza database per rendere effettive le modifiche. Per ulteriori informazioni, vedi il parametro [apg\$1plan\$1mgmt.max\$1plans](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.max_plans).
## Convalida dei piani
Usa la funzione `apg_plan_mgmt.validate_plans` per eliminare o disabilitare i piani non validi.
I piani possono diventare non validi (obsoleti) quando gli oggetti da cui dipendono vengono rimossi, ad esempio un indice o una tabella. Tuttavia, un piano potrebbe diventare non valido solo temporaneamente se l'oggetto rimosso viene poi ricreato. Se un piano non valido può diventare successivamente valido, potresti preferire di disabilitare un piano non valido o non fare nulla anziché eliminarlo.
Per trovare ed eliminare tutti i piani che non sono validi e non sono stati utilizzati nell'ultima settimana, utilizza la funzione `apg_plan_mgmt.validate_plans `come segue.
```
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');
```
Per abilitare o disabilitare un piano direttamente, utilizza la funzione `apg_plan_mgmt.set_plan_enabled`.
# Esportazione e importazione dei piani gestiti per Aurora PostgreSQL
Puoi esportare i piani gestiti e importarli in un'altra istanza database.
**Per esportare i piani gestiti**
Un utente autorizzato può copiare qualsiasi sottoinsieme della tabella `apg_plan_mgmt.plans` in un'altra tabella e quindi salvarlo utilizzando il comando `pg_dump`. Di seguito è riportato un esempio.
```
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;
```
**Per importare i piani gestiti**
1. Copiare il file .tar dei piani gestiti esportati nel percorso di sistema in cui devono essere ripristinati i piani.
1. Usare il comando `pg_restore` per copiare il file tar in una nuova tabella.
```
% pg_restore --dbname mytargetdatabase -Ft plans_copy.tar
```
1. Unire la tabella `plans_copy` alla tabella `apg_plan_mgmt.plans`, come mostrato nell'esempio seguente.
**Nota**
In alcuni casi, potresti dover eseguire il dump da una versione dell'estensione `apg_plan_mgmt` e ripristinarlo in una versione diversa. In questi casi, le colonne nella tabella dei piani potrebbero essere diverse. In tal caso, denominare le colonne esplicitamente anziché utilizzare 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. Ricaricare i piani gestiti nella memoria condivisa e rimuovere la tabella dei piani temporanei.
```
SELECT apg_plan_mgmt.reload(); -- refresh shared memory
DROP TABLE plans_copy;
```
# Documentazione di riferimento dei parametri per la gestione del piano di query Aurora PostgreSQL
È possibile impostare le preferenze per l’estensione `apg_plan_mgmt` utilizzando i parametri elencati in questa sezione. Questi sono disponibili nel parametro del cluster database personalizzato e nel gruppo di parametri DB associato al cluster database Aurora PostgreSQL. Questi parametri controllano il comportamento della funzionalità di gestione del piano di query e in che modo influenza l'ottimizzatore. Per informazioni su come impostare la gestione del piano di query, consulta [Attivazione della gestione del piano di query per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md#AuroraPostgreSQL.Optimize.Enable). La modifica dei seguenti parametri non ha effetto se l’estensione `apg_plan_mgmt` non è impostata come descritto in tale sezione. Per informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md) e [Gruppi di parametri database per istanze database 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
Acquisisce i piani di esecuzione delle query generati dall'ottimizzatore per ogni istruzione SQL e li memorizza nella vista `dba_plans`. Per impostazione predefinita, il numero massimo di piani che è possibile memorizzare è 10.000, come specificato dal parametro `apg_plan_mgmt.max_plans`. Per informazioni di riferimento, consulta [apg\$1plan\$1mgmt.max\$1plans](#AuroraPostgreSQL.Optimize.Parameters.max_plans).
Questo parametro può essere impostato nel gruppo di parametri del cluster database personalizzato o nel gruppo di parametri DB personalizzato. La modifica del valore di questo parametro non richiede un riavvio.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
Per ulteriori informazioni, consulta [Acquisizione dei piani di esecuzione Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
## apg\$1plan\$1mgmt.plan\$1capture\$1threshold
Specifica una soglia in modo che se il costo totale del piano di esecuzione delle query è inferiore alla soglia, il piano non venga acquisito nella vista `apg_plan_mgmt.dba_plans`.
La modifica del valore di questo parametro non richiede un riavvio.
| Predefinita | Valori consentiti | Description |
| --- | --- | --- |
| 0 | 0 - 1.79769e\$1308 | Imposta la soglia del costo totale di esecuzione del piano di query `apg_plan_mgmt` per l'acquisizione dei piani. |
Per ulteriori informazioni, consulta [Esame dei piani di query Aurora PostgreSQL nella vista dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.explain\$1hashes
Specifica se `EXPLAIN [ANALYZE]` mostra `sql_hash` e `plan_hash` alla fine del relativo output. La modifica del valore di questo parametro non richiede un riavvio.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.log\$1plan\$1enforcement\$1result
Specifica se i risultati devono essere registrati per verificare se i piani gestiti dalla funzionalità di gestione dei piani di query vengono utilizzati correttamente. Quando viene utilizzato un piano generico archiviato, non verrà scritto alcun record nei file di log. La modifica del valore di questo parametro non richiede un riavvio.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.max\$1databases
Specifica il numero massimo di database sull'istanza di scrittura del cluster database Aurora PostgreSQL che possono utilizzare la gestione del piano di query. L'impostazione predefinita è 10 database. Se sull'istanza sono presenti più di 10 database, il valore dell'impostazione può essere modificato. Per scoprire quanti database sono presenti in una determinata istanza, connettersi all'istanza utilizzando `psql`. Quindi, utilizzare il metacomando psql, `\l`, per elencare i database.
La modifica del valore di questo parametro richiede il riavvio dell'istanza affinché l'impostazione diventi effettiva.
| Predefinita | Valori consentiti | Description |
| --- | --- | --- |
| 10 | 10-2147483647 | Numero massimo di database che possono utilizzare la gestione del piano di query sull’istanza. |
Questo parametro può essere impostato nel gruppo di parametri del cluster database personalizzato o nel gruppo di parametri DB personalizzato.
## apg\$1plan\$1mgmt.max\$1plans
Imposta il numero massimo di istruzioni SQL che il gestore del piano di query può mantenere nella visualizzazione `apg_plan_mgmt.dba_plans`. Si consiglia di impostare questo parametro su `10000` o superiore per tutte le versioni di Aurora PostgreSQL.
Questo parametro può essere impostato nel gruppo di parametri del cluster database personalizzato o nel gruppo di parametri DB personalizzato. La modifica del valore di questo parametro richiede il riavvio dell'istanza affinché l'impostazione diventi effettiva.
| Predefinita | Valori consentiti | Description |
| --- | --- | --- |
| 10000 | 10-2147483647 | Numero massimo di piani che possono essere archiviati nella vista `apg_plan_mgmt.dba_plans`. Il valore predefinito per Aurora PostgreSQL versione 10 e versioni precedenti è 1000. |
Per ulteriori informazioni, consulta [Esame dei piani di query Aurora PostgreSQL nella vista dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.plan\$1hash\$1version
Specifica i casi d'uso che il calcolo plan\$1hash è progettato per coprire. Una versione superiore di `apg_plan_mgmt.plan_hash_version` copre tutte le funzionalità della versione inferiore. Ad esempio, la versione 3 copre i casi d'uso supportati dalla versione 2.
La modifica del valore di questo parametro deve essere seguita da una chiamata a `apg_plan_mgmt.validate_plans('update_plan_hash')`. Aggiorna i valori plan\$1hash in ogni database con apg\$1plan\$1mgmt installato e le voci nella tabella dei piani. Per ulteriori informazioni, consulta [Convalida dei piani](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.plan\$1retention\$1period
Specifica il numero di giorni per cui si desidera mantenere i piani nella vista `apg_plan_mgmt.dba_plans` prima che vengano eliminati automaticamente. Per impostazione predefinita, un piano viene eliminato quando sono trascorsi 32 giorni dall'ultimo utilizzo del piano (la colonna `last_used` nella vista `apg_plan_mgmt.dba_plans`). Questa impostazione può essere modificata in un numero qualsiasi, 1 e valori superiori.
La modifica del valore di questo parametro richiede il riavvio dell'istanza affinché l'impostazione diventi effettiva.
| Predefinita | Valori consentiti | Description |
| --- | --- | --- |
| 32 | 1-2147483647 | Numero massimo di giorni dall'ultimo utilizzo di un piano prima che venga eliminato. |
Per ulteriori informazioni, consulta [Esame dei piani di query Aurora PostgreSQL nella vista dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold
Specifica una soglia di costo al di sotto della quale un piano non approvato può essere utilizzato dall'ottimizzatore. La soglia è 0 per impostazione predefinita, in modo che l'ottimizzatore non esegua piani non approvati. L'impostazione di questo parametro su una soglia di costo estremamente bassa, ad esempio 100, evita il sovraccarico di applicazione del piano nei piani banali. È inoltre possibile impostare questo parametro su un valore estremamente elevato, ad esempio 10000000, utilizzando lo stile reattivo di gestione del piano. Ciò consente all'ottimizzatore di utilizzare tutti i piani scelti senza generare sovraccarichi dovuti all'applicazione del piano. Tuttavia, quando viene trovato un piano errato, è possibile contrassegnarlo manualmente come "rejected" in modo che non venga utilizzato la volta successiva.
Il valore di questo parametro rappresenta una stima dei costi per l'esecuzione di un determinato piano. Se il costo di un piano non approvato è inferiore a tale costo stimato, verrà utilizzato dall'ottimizzatore per l'istruzione SQL. I piani acquisiti e il relativo stato (Approvato, Non approvato) sono visibili nella vista `dba_plans`. Per ulteriori informazioni, consulta [Esame dei piani di query Aurora PostgreSQL nella vista dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
La modifica del valore di questo parametro non richiede un riavvio.
| Predefinita | Valori consentiti | Description |
| --- | --- | --- |
| 0 | 0-2147483647 | Costo del piano stimato al di sotto del quale viene utilizzato un piano non approvato. |
Per ulteriori informazioni, consulta [Utilizzo dei piani gestiti per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md).
## apg\$1plan\$1mgmt.use\$1plan\$1baselines
Specifica che l'ottimizzatore deve utilizzare uno dei piani approvati acquisiti e archiviati nella vista `apg_plan_mgmt.dba_plans`. Per impostazione predefinita, questo parametro è disattivato (false). Di conseguenza, l'ottimizzatore utilizzerà il piano a costo minimo che genera senza un'ulteriore valutazione. L'attivazione di questo parametro (impostandolo su true) obbliga l'ottimizzatore a scegliere un piano di esecuzione della query per l'istruzione dalla sua baseline del piano. Per ulteriori informazioni, consulta [Utilizzo dei piani gestiti per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md). Per trovare un'immagine che descrive questo processo, consulta [In che modo l'ottimizzatore sceglie quale piano eseguire.](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans).
Questo parametro può essere impostato nel gruppo di parametri del cluster database personalizzato o nel gruppo di parametri DB personalizzato. La modifica del valore di questo parametro non richiede un riavvio.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
I tempi di risposta dei diversi piani acquisiti possono essere valutati e lo stato del piano modificato, in base alle esigenze. Per ulteriori informazioni, consulta [Miglioramento dei piani di query di Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.md).
## auto\$1explain.hashes
Specifica se l'output di auto\$1explain mostra sql\$1hash e plan\$1hash. La modifica del valore di questo parametro non richiede un riavvio.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
# Informazioni di riferimento sulle funzioni per la gestione del piano di query Aurora PostgreSQL
L'estensione `apg_plan_mgmt` fornisce le seguenti funzioni.
**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 determinato hash e una struttura del piano SQL in un hash e una struttura del piano SQL di destinazione, sovrascrivendo così l'hash e la struttura del piano di destinazione. Questa funzione è disponibile in `apg_plan_mgmt` 2.3 e versioni successive.
**Sintassi**
```
apg_plan_mgmt.copy_outline(
source_sql_hash,
source_plan_hash,
target_sql_hash,
target_plan_hash,
force_update_target_plan_hash
)
```
**Valore restituito**
Restituisce 0 quando la copia ha esito positivo. Genera eccezioni per gli input non validi.
**Parametri**
****
| Parametro | Description |
| --- | --- |
| source\$1sql\$1hash | L'ID sql\$1hash associato al plan\$1hash da copiare nella query di destinazione. |
| source\$1plan\$1hash | L'ID plan\$1hash da copiare nella query di destinazione. |
| target\$1sql\$1hash | L'ID sql\$1hash della query da aggiornare con l'hash e la struttura del piano di origine. |
| target\$1plan\$1hash | L'ID plan\$1hash della query da aggiornare con l'hash e la struttura del piano di origine. |
| force\$1update\$1target\$1plan\$1hash | (Facoltativo) L’ID target\$1plan\$1hash della query viene aggiornato anche se il piano di origine non è riproducibile per target\$1sql\$1hash. Se impostata su true, la funzione può essere utilizzata per copiare i piani tra schemi in cui le colonne e i nomi delle relazioni sono coerenti. |
**Note per l'utilizzo**
Questa funzione consente di copiare un hash e una struttura del piano che utilizza i suggerimenti per altre dichiarazioni simili e quindi evita la necessità di usare istruzioni di suggerimento in linea ad ogni occorrenza nelle istruzioni di destinazione. Se la query di destinazione aggiornata genera un piano non valido, questa funzione restituisce un errore ed esegue il rollback del tentativo di aggiornamento.
## apg\$1plan\$1mgmt.delete\$1plan
Elimina un piano gestito.
**Sintassi**
```
apg_plan_mgmt.delete_plan(
sql_hash,
plan_hash
)
```
**Valore restituito**
Restituisce 0 se l'eliminazione ha esito positivo o -1 se l'eliminazione non riesce.
**Parametri**
****
| Parametro | Descrizione |
| --- | --- |
| sql\$1hash | L'ID sql\$1hash dell'istruzione SQL gestita del piano. |
| plan\$1hash | L'ID plan\$1hash del piano gestito. |
## apg\$1plan\$1mgmt.evolve\$1plan\$1baselines
Verifica se un piano già approvato è più veloce o se un piano identificato dall'ottimizzatore di query come piano a costo minimo è più veloce.
**Sintassi**
```
apg_plan_mgmt.evolve_plan_baselines(
sql_hash,
plan_hash,
min_speedup_factor,
action
)
```
**Valore restituito**
Il numero di piani che non sono più veloci del miglior piano approvato.
**Parametri**
****
| Parametro | Descrizione |
| --- | --- |
| sql\$1hash | L'ID sql\$1hash dell'istruzione SQL gestita del piano. |
| plan\$1hash | L'ID plan\$1hash del piano gestito. Utilizza NULL per indicare tutti i piani che hanno lo stesso valore di ID sql\$1hash. |
| min\$1speedup\$1factor | Il *fattore di velocità minima* indica quante volte un piano deve essere più veloce per essere approvato rispetto al migliore dei piani già approvati In alternativa, questo fattore può corrispondere quante volte deve essere più lento per essere rifiutato o disabilitato. Questo è un valore float positivo. |
| action | L'azione che deve essere eseguita dalla funzione. I valori validi includono i seguenti. Non c'è distinzione tra lettere maiuscole e minuscole. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) |
**Note per l'utilizzo**
Imposta i piani specificati su approvato, rifiutato o disabilitato in base al fatto che la pianificazione più il tempo di esecuzione sia più veloce del migliore piano approvato da un fattore che puoi impostare. Il parametro action può essere impostato su `'approve'` o `'reject'` per approvare o rifiutare automaticamente un piano che soddisfa i criteri di prestazione. In alternativa, potrebbe essere impostato su '' (stringa vuota) per eseguire l'esperimento sulle prestazioni e produrre un report, senza intraprendere alcuna azione.
Puoi evitare di rieseguire inutilmente la funzione `apg_plan_mgmt.evolve_plan_baselines` per un piano su cui è stata eseguita di recente. Per farlo, limita i piani solo a quelli creati di recente e non ancora approvati. In alternativa, puoi evitare di eseguire la funzione `apg_plan_mgmt.evolve_plan_baselines` su qualsiasi piano approvato che abbia un timestamp recente `last_verified`.
Conduci un esperimento delle prestazioni per confrontare la pianificazione più il tempo di esecuzione di ciascun piano rispetto agli altri piani nella baseline. In alcuni casi, esiste un solo piano per un'istruzione e il piano è approvato. In tal caso, confronta la pianificazione più il tempo di esecuzione del piano con la pianificazione più il tempo di esecuzione dell'utilizzo di nessun piano.
Il vantaggio (o lo svantaggio) incrementale di ciascun piano è registrato nella visualizzazione `apg_plan_mgmt.dba_plans` nella colonna `total_time_benefit_ms`. Quando questo valore è positivo, c'è un vantaggio misurabile in termini di prestazioni per includere questo piano nella baseline.
Oltre a raccogliere i tempi di pianificazione ed esecuzione di ogni piano candidato, la colonna `last_verified` della visualizzazione `apg_plan_mgmt.dba_plans` viene aggiornata con il `current_timestamp`. È possibile utilizzare il time stamp `last_verified` per evitare di eseguire nuovamente questa funzione su un piano le cui prestazioni sono state verificate di recente.
## apg\$1plan\$1mgmt.get\$1explain\$1plan
Genera il testo di una istruzione `EXPLAIN` per l'istruzione SQL specificata.
**Sintassi**
```
apg_plan_mgmt.get_explain_plan(
sql_hash,
plan_hash,
[explainOptionList]
)
```
**Valore restituito**
Restituisce le statistiche di runtime per le istruzioni SQL specificate. Utilizzare senza `explainOptionList` per restituire un piano `EXPLAIN` semplice.
**Parametri**
****
| Parametro | Descrizione |
| --- | --- |
| sql\$1hash | L'ID sql\$1hash dell'istruzione SQL gestita del piano. |
| plan\$1hash | L'ID plan\$1hash del piano gestito. |
| explainOptionList | Un elenco separato da virgole di opzioni di spiegazione. I valori validi includono `'analyze'`, `'verbose'`, `'buffers'`, `'hashes'` e `'format json'`. Se l'elenco di `explainOptionList` è NULL o una stringa vuota ("), questa funzione genera un’istruzione `EXPLAIN`, senza alcuna statistica. |
**Note per l'utilizzo**
Per il `explainOptionList`, è possibile utilizzare una delle stesse opzioni che si utilizzerebbe con una istruzione `EXPLAIN`. L'ottimizzatore Aurora PostgreSQL concatena l'elenco delle opzioni fornite all'istruzione `EXPLAIN`.
## apg\$1plan\$1mgmt.plan\$1last\$1used
Restituisce la data `last_used` del piano specificato dalla memoria condivisa.
**Nota**
Il valore nella memoria condivisa è sempre aggiornato sull'istanza database primaria nel cluster database. Il valore viene scaricato solo periodicamente nella colonna `last_used` della visualizzazione `apg_plan_mgmt.dba_plans`.
**Sintassi**
```
apg_plan_mgmt.plan_last_used(
sql_hash,
plan_hash
)
```
**Valore restituito**
Restituisce la data `last_used`.
**Parametri**
****
| Parametro | Descrizione |
| --- | --- |
| sql\$1hash | L'ID sql\$1hash dell'istruzione SQL gestita del piano. |
| plan\$1hash | L'ID plan\$1hash del piano gestito. |
## apg\$1plan\$1mgmt.reload
Ricarica i piani nella memoria condivisa dalla visualizzazione `apg_plan_mgmt.dba_plans`.
**Sintassi**
```
apg_plan_mgmt.reload()
```
**Valore restituito**
Nessuna.
**Parametri**
Nessuna.
**Note per l'utilizzo**
Chiama `reload` per le seguenti situazioni:
+ Usalo per aggiornare immediatamente la memoria condivisa di una replica di sola lettura, invece di aspettare che i nuovi piani si propaghino alla replica.
+ Usalo dopo l'importazione dei piani gestiti.
## apg\$1plan\$1mgmt.set\$1plan\$1enabled
Abilita o disabilita un piano gestito.
**Sintassi**
```
apg_plan_mgmt.set_plan_enabled(
sql_hash,
plan_hash,
[true | false]
)
```
**Valore restituito**
Restituisce 0 se l'impostazione ha esito positivo o -1 se l'impostazione non riesce.
**Parametri**
****
| Parametro | Descrizione |
| --- | --- |
| sql\$1hash | L'ID sql\$1hash dell'istruzione SQL gestita del piano. |
| plan\$1hash | L'ID plan\$1hash del piano gestito. |
| enabled | Valore booleano true o false: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) |
## apg\$1plan\$1mgmt.set\$1plan\$1status
Impostare lo stato di un piano gestito su `Approved`, `Unapproved`, `Rejected` o `Preferred`.
**Sintassi**
```
apg_plan_mgmt.set_plan_status(
sql_hash,
plan_hash,
status
)
```
**Valore restituito**
Restituisce 0 se l'impostazione ha esito positivo o -1 se l'impostazione non riesce.
**Parametri**
****
| Parametro | Descrizione |
| --- | --- |
| sql\$1hash | L'ID sql\$1hash dell'istruzione SQL gestita del piano. |
| plan\$1hash | L'ID plan\$1hash del piano gestito. |
| status | Stringa con uno dei seguenti valori: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) Il caso utilizzato non ha importanza, tuttavia il valore di stato è impostato su maiuscole iniziali nella vista `apg_plan_mgmt.dba_plans`. Per ulteriori informazioni su questi valori, consulta `status` in [Riferimento per la visualizzazione apg\$1plan\$1mgmt.dba\$1plans per Aurora edizione compatibile con PostgreSQL](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md). |
## apg\$1plan\$1mgmt.update\$1plans\$1last\$1used
Aggiorna immediatamente la tabella dei piani con la data `last_used` memorizzata nella memoria condivisa.
**Sintassi**
```
apg_plan_mgmt.update_plans_last_used()
```
**Valore restituito**
Nessuna.
**Parametri**
Nessuna.
**Note per l'utilizzo**
Eseguire una chiamata a `update_plans_last_used` per assicurarsi che le query contro la colonna `dba_plans.last_used` utilizzino le informazioni più aggiornate. Se il la data `last_used` non viene aggiornata immediatamente, un processo in background aggiorna la tabella dei piani con la data `last_used` una volta ogni ora (per impostazione predefinita).
Ad esempio, se un'istruzione con una certa `sql_hash` inizia a funzionare lentamente, è possibile determinare quali piani per quell'istruzione sono stati eseguiti dall'inizio della regressione delle prestazioni. Per fare ciò, innanzitutto svuotare i dati nella memoria condivisa su disco in modo che le date `last_used` siano correnti e quindi interroghino tutti i piani dell'istruzione `sql_hash` con la regressione delle prestazioni. Nella query, assicurati che la data `last_used` sia maggiore o uguale alla data in cui è iniziata la regressione delle prestazioni. La query identifica il piano o l'insieme di piani che potrebbero essere responsabili della regressione delle prestazioni. È possibile utilizzare `apg_plan_mgmt.get_explain_plan` con `explainOptionList` impostato su `verbose, hashes`. È possibile utilizzare anche `apg_plan_mgmt.evolve_plan_baselines` per analizzare il piano e qualsiasi piano alternativo che potrebbe funzionare meglio.
La funzione `update_plans_last_used` ha un effetto solo sull'istanza database primaria del cluster database.
## apg\$1plan\$1mgmt.validate\$1plans
Convalida che l'ottimizzatore può ancora ricreare piani. L'ottimizzatore convalida i piani `Approved`, `Unapproved` e `Preferred`, se il piano è abilitato o disabilitato. I piani `Rejected` non sono convalidati. Facoltativamente, puoi utilizzare la funzione `apg_plan_mgmt.validate_plans` per eliminare o disabilitare i piani non validi.
**Sintassi**
```
apg_plan_mgmt.validate_plans(
sql_hash,
plan_hash,
action)
apg_plan_mgmt.validate_plans(
action)
```
**Valore restituito**
Numero di piani non validi.
**Parametri**
****
| Parametro | Descrizione |
| --- | --- |
| sql\$1hash | L'ID sql\$1hash dell'istruzione SQL gestita del piano. |
| plan\$1hash | L'ID plan\$1hash del piano gestito. Utilizza NULL per indicare tutti i piani con lo stesso valore di ID sql\$1hash. |
| action | L'azione che deve essere eseguita dalla funzione per i piani non validi. I valori di stringa validi includono i seguenti: Non c'è distinzione tra lettere maiuscole e minuscole. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) Qualsiasi altro valore viene considerato come una stringa vuota. |
**Note per l'utilizzo**
Usa il modulo `validate_plans(action)` per convalidare tutti i piani gestiti per tutte le istruzioni gestite nell'intera visualizzazione `apg_plan_mgmt.dba_plans`.
Usa il modulo `validate_plans(sql_hash, plan_hash, action)` per convalidare un piano gestito specificato con `plan_hash`, per un'istruzione gestita specificata con `sql_hash`.
Usa il modulo `validate_plans(sql_hash, NULL, action)` per convalidare tutti i piani gestiti per l'istruzione gestita specificata con `sql_hash`.
# Riferimento per la visualizzazione apg\$1plan\$1mgmt.dba\$1plans per Aurora edizione compatibile con PostgreSQL
Le colonne del piano nella visualizzazione `apg_plan_mgmt.dba_plans` includono le seguenti.
| Colonna dba\$1plans | Descrizione |
| --- | --- |
| cardinality\$1error | Misura dell'errore tra la cardinalità stimata e alla cardinalità effettiva. *Cardinality* è il numero di righe della tabella che saranno elaborate dal piano. Se l'errore di cardinalità è ampio, aumenta la probabilità che il piano non sia ottimale. Questa colonna è popolata dalla funzione [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| compatibility\$1level | Questo parametro mostra la data dell’ultima convalida di un piano di query. In Aurora PostgreSQL versioni 12.19, 13.15, 14.12, 15.7, 16.3 e successive, visualizza il numero di versione di Aurora. Per le versioni precedenti, visualizza un numero di versione specifico della funzionalità. Mantenere questo parametro sul valore predefinito. Aurora PostgreSQL imposta e aggiorna automaticamente questo valore. |
| created\$1by | L'utente autenticato (session\$1user) che ha creato il piano. |
| enabled | Indicatore che mostra se il piano è abilitato o disabilitato. Tutte i piani sono abilitati per impostazione predefinita. Puoi disabilitare i piani per impedire che vengano utilizzati dall'ottimizzatore. Per modificare questo valore, utilizza la funzione [apg\$1plan\$1mgmt.set\$1plan\$1enabled](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.set_plan_enabled). |
| environment\$1variables | Parametri e valori PostgreSQL Grand Unified Configuration (GUC) che l'ottimizzatore ha ignorato nel momento in cui è stato acquisito il piano. |
| estimated\$1startup\$1cost | Il costo di installazione stimato dell'ottimizzatore prima che fornisca le righe di una tabella. |
| estimated\$1total\$1cost | Il costo dell'ottimizzatore stimato per la consegna della riga finale della tabella. |
| execution\$1time\$1benefit\$1ms | Il tempo di esecuzione beneficia in termini di millisecondi dell'abilitazione del piano. Questa colonna è popolata dalla funzione [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| execution\$1time\$1ms | Il tempo stimato di esecuzione del piano in millisecondi. Questa colonna è popolata dalla funzione [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| has\$1side\$1effects | Valore che indica che l'istruzione SQL è un'istruzione DML (Data Manipulation Language) o un'istruzione SELECT che contiene una funzione VOLATILE. |
| last\$1used | Questo valore viene aggiornato alla data corrente ogni volta che il piano viene eseguito o quando il piano è il piano a costo minimo dell'ottimizzatore di query. Questo valore è archiviato nella memoria condivisa e periodicamente viene riportato su disco. Per ottenere il massimo up-to-date valore, leggi la data dalla memoria condivisa chiamando la funzione apg\$1plan\$1mgmt.plan\$1last\$1used(sql\$1hash, plan\$1hash) invece di leggere il last\$1used valore. Per ulteriori informazioni, vedi il parametro [apg\$1plan\$1mgmt.plan\$1retention\$1period](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.plan_retention_period). |
| last\$1validated | La data e l'ora della verifica più recente del piano che potrebbe essere ricreato dalla funzione [apg\$1plan\$1mgmt.validate\$1plans](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.validate_plans) o [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| last\$1verified | La data e l'ora della verifica più recente di un piano come il piano più performante per i parametri specificati dalla funzione [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| origin | Come il piano è stato acquisito con il parametro [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines). I valori validi includono i seguenti: `M` – Il piano è stato acquisito con l'acquisizione manuale del piano. `A` – Il piano è stato acquisito con l'acquisizione automatica del piano. |
| param\$1list | I valori dei parametri che sono stati passati all'istruzione se è un'istruzione preparata. |
| plan\$1created | La data e l'ora di creazione del piano. |
| plan\$1hash | Identificatore del piano. La combinazione di plan\$1hash e sql\$1hash identifica in modo univoco un piano specifico. |
| plan\$1outline | Rappresentazione del piano che viene utilizzata per ricreare il piano di esecuzione effettivo e che è indipendente dal database. Gli operatori nella struttura ad albero corrispondono agli operatori presenti nell'output di EXPLAIN. |
| planning\$1time\$1ms | Il tempo effettivo per eseguire il pianificatore, in millisecondi. Questa colonna è popolata dalla funzione [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| queryId | Un hash dell'istruzione, come calcolato dall'estensione pg\$1stat\$1statements. Questo non è un identificatore stabile o indipendente dal database perché dipende dagli identificatori di oggetti (). OIDs Il valore sarà 0 se compute\$1query\$1id è off durante l'acquisizione del piano di query. |
| sql\$1hash | Valore hash del testo dell'istruzione SQL, normalizzato con valori letterali rimossi. |
| sql\$1text | Il testo completo dell'istruzione SQL. |
| status | Lo stato di un piano che determina il modo in cui l'ottimizzatore utilizza un piano. I valori validi includono i seguenti. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.dba_plans_view_Reference.html) |
| stmt\$1name | Il nome dell'istruzione SQL all'interno di un'istruzione PREPARE. Questo valore è una stringa vuota per un'istruzione preparata senza nome. Questo valore è NULL per un'istruzione non preparata. |
| total\$1time\$1benefit\$1ms | Il vantaggio in termini di tempo totale in millisecondi derivato dall'abilitazione di questo piano. Questo valore considera sia il tempo di pianificazione che il tempo di esecuzione. Se il valore è negativo, non è vantaggioso abilitare questo piano. Questa colonna è popolata dalla funzione [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
# Funzionalità avanzate della gestione del piano di query
Di seguito sono disponibili informazioni sulle funzionalità avanzate della gestione dei piani di query (QPM) di Aurora PostgreSQL:
**Topics**
+ [Acquisizione dei piani di esecuzione Aurora PostgreSQL nelle repliche](AuroraPostgreSQL.QPM.Plancapturereplicas.md)
+ [Supporto della partizione di tabelle](AuroraPostgreSQL.QPM.Partitiontable.md)
# Acquisizione dei piani di esecuzione Aurora PostgreSQL nelle repliche
QPM (Query Plan Management) consente di acquisire i piani di query generati dalle repliche di Aurora e di archiviarli sull'istanza database principale del cluster di database Aurora. È possibile raccogliere i piani di query da tutte le repliche Aurora e mantenere un insieme di piani ottimali in una tabella centrale persistente sull'istanza primaria. Potrai applicare tali piani su altre repliche secondo necessità. Ciò consente di mantenere la stabilità dei piani di esecuzione e di migliorare le prestazioni delle query tra i cluster database e le versioni del motore.
**Topics**
+ [Prerequisiti](#AuroraPostgreSQL.QPM.Plancapturereplicas.Prereq)
+ [Gestione dell'acquisizione del piano per le repliche di Aurora](#AuroraPostgreSQL.QPM.Plancapturereplicas.managing)
+ [Risoluzione dei problemi](#AuroraPostgreSQL.QPM.Plancapturereplicas.Troubleshooting)
## Prerequisiti
**Attiva `capture_plan_baselines parameter` in una replica di Aurora**: imposta il parametro `capture_plan_baselines` su automatico o manuale per acquisire i piani nelle repliche di Aurora. Per ulteriori informazioni, consulta [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines).
**Installa l'estensione postgres\$1fdw**: è necessario installare l'estensione foreign data wrapper `postgres_fdw` per acquisire i piani nelle repliche di Aurora. Per installare l'estensione, esegui il comando seguente in ogni database.
```
postgres=> CREATE EXTENSION IF NOT EXISTS postgres_fdw;
```
## Gestione dell'acquisizione del piano per le repliche di Aurora
**Attiva l'acquisizione del piano per le repliche di Aurora**
Per creare o rimuovere l'acquisizione del piano nelle repliche Aurora devi disporre dei privilegi di `rds_superuser`. Per ulteriori informazioni sui ruoli e le autorizzazioni degli utenti, consulta [Informazioni su ruoli e autorizzazioni di PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Roles.html).
Per acquisire i piani, chiama la funzione apg\$1plan\$1mgmt.create\$1replica\$1plan\$1capture nell'istanza database di scrittura, come illustrato di seguito:
```
postgres=> CALL apg_plan_mgmt.create_replica_plan_capture('endpoint', 'password');
```
+ endpoint: l’endpoint di scrittura del database globale Aurora o cluster\$1endpoint fornisce il supporto del failover per l’acquisizione del piano nelle repliche Aurora.
Per ulteriori informazioni sull’endpoint di scrittura del database globale Aurora, consulta [Visualizzazione degli endpoint di un database globale Amazon Aurora](aurora-global-database-connecting.md#viewing-endpoints).
Per ulteriori informazioni sugli endpoint del cluster, consulta [Endpoint del cluster per Amazon Aurora](Aurora.Endpoints.Cluster.md).
+ password: per migliorare la sicurezza, ti consigliamo di seguire queste linee guida durante la creazione della password:
+ Deve contenere almeno 8 caratteri.
+ Deve contenere almeno una lettera maiuscola, una lettera minuscola e un numero.
+ Deve contenere almeno un carattere speciale (`?`, `!`, `#`, `<`, `>`, `*`, eccetera).
**Nota**
Se modifichi l’endpoint, la password o il numero di porta, è necessario eseguire nuovamente l’operazione `apg_plan_mgmt.create_replica_plan_capture()` con l’endpoint e la password per reinizializzare l’acquisizione del piano. In caso contrario, l'acquisizione dei piani dalle repliche Aurora genererà un errore.
**Disattiva l'acquisizione del piano per le repliche Aurora**
È possibile disattivare il parametro `capture_plan_baselines` nelle repliche Aurora impostandone il valore su `off` nel gruppo Parametri.
**Rimuovi l'acquisizione del piano per le repliche Aurora**
È possibile rimuovere completamente l'acquisizione dei piani per le repliche Aurora, ma prima di farlo ti consigliamo di rifletterci bene. Per rimuovere l'acquisizione dei piani, chiama `apg_plan_mgmt.remove_replica_plan_capture` come mostrato:
```
postgres=> CALL apg_plan_mgmt.remove_replica_plan_capture();
```
Per attivare l’acquisizione del piano nelle repliche Aurora con l’endpoint e la password, è necessario chiamare nuovamente apg\$1plan\$1mgmt.create\$1replica\$1plan\$1capture().
## Risoluzione dei problemi
Di seguito, è possibile trovare idee per la risoluzione dei problemi e soluzioni alternative se il piano non viene acquisito come previsto nelle repliche Aurora.
+ **Impostazioni dei parametri**: controlla se il parametro `capture_plan_baselines` è impostato sul valore corretto per attivare l'acquisizione del piano.
+ **L'estensione `postgres_fdw` è installata**: utilizza la seguente query per verificare se `postgres_fdw` è installata.
```
postgres=> SELECT * FROM pg_extension WHERE extname = 'postgres_fdw'
```
+ **create\$1replica\$1plan\$1capture() è stata chiamata**: utilizza il seguente comando per verificare se la mappatura dell'utente è presente. Altrimenti, chiama `create_replica_plan_capture()` per inizializzare la funzionalità.
```
postgres=> SELECT * FROM pg_foreign_server WHERE srvname = 'apg_plan_mgmt_writer_foreign_server';
```
+ **Endpoint e numero di porta**: controllare se l’endpoint e il numero di porta sono corretti. Quando questi valori sono errati, non viene visualizzato alcun messaggio di errore.
Utilizza il seguente comando per verificare se l'endpoint è utilizzato in create() e per controllare in quale database risiede:
```
postgres=> SELECT srvoptions FROM pg_foreign_server WHERE srvname = 'apg_plan_mgmt_writer_foreign_server';
```
+ **reload()**: è necessario chiamare apg\$1plan\$1mgmt.reload() dopo aver chiamato apg\$1plan\$1mgmt.delete\$1plan() nelle repliche Aurora per rendere effettiva la funzione di eliminazione. Ciò garantisce che la modifica sia stata implementata con successo.
+ **Password**: è necessario inserire la password in create\$1replica\$1plan\$1capture() seguendo le linee guida menzionate. In caso contrario, verrà restituito un errore. Per ulteriori informazioni, consulta [Gestione dell'acquisizione del piano per le repliche di Aurora](#AuroraPostgreSQL.QPM.Plancapturereplicas.managing). Utilizza un'altra password che soddisfi i requisiti.
+ **Connessione tra più regioni**: l'acquisizione dei piani nelle repliche di Aurora è supportata anche nel database globale Aurora, dove l'istanza di scrittura e le repliche Aurora possono trovarsi in regioni diverse. Assicurarsi di utilizzare l’endpoint di scrittura del database globale Aurora per mantenere la connettività dopo eventi di failover o switchover. Per ulteriori informazioni sugli endpoint del database globale Aurora, consulta [Visualizzazione degli endpoint di un database globale Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-connecting.html#viewing-endpoints). L'istanza di scrittura e la replica che si trovano in regioni diverse devono essere in grado di comunicare utilizzando il Peering VPC. Per ulteriori informazioni, consulta [Peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html). Se si verifica un failover che coinvolge più regioni, è necessario riconfigurare l'endpoint su un nuovo endpoint primario del cluster di database.
**Nota**
Quando si utilizza un endpoint del cluster anziché un endpoint di scrittura del database globale Aurora, è necessario aggiornare l’endpoint del cluster dopo aver eseguito un’operazione di failover globale o di switchover.
# Supporto della partizione di tabelle
La funzionalità di gestione dei piani di query (QPM) di Aurora PostgreSQL supporta il partizionamento dichiarativo delle tabelle nelle seguenti versioni:
+ 15.3 o versioni successive alla 15
+ 14.8 o versioni successive alla 14
+ 13.11 o versioni successive alla 13
Per ulteriori informazioni, consulta la pagina relativa al [partizionamento delle tabelle](https://www.postgresql.org/docs/current/ddl-partitioning.html).
**Topics**
+ [Configurazione della partizione delle tabelle](#AuroraPostgreSQL.QPM.Partitiontable.setup)
+ [Acquisizione dei piani per la partizione delle tabelle](#AuroraPostgreSQL.QPM.Partitiontable.capture)
+ [Applicazione di un piano di partizione delle tabelle](#AuroraPostgreSQL.QPM.Partitiontable.enforcement)
+ [Convenzione di denominazione](#AuroraPostgreSQL.QPM.Partitiontable.naming.convention)
## Configurazione della partizione delle tabelle
Per configurare la partizione delle tabelle nella funzionalità di gestione dei piani di query di Aurora PostgreSQL, procedi come segue:
1. Imposta `apg_plan_mgmt.plan_hash_version` su 3 o un valore maggiore nel gruppo di parametri del cluster database.
1. Accedi a un database che utilizza la funzionalità di gestione dei piani di query e che contiene voci nella vista `apg_plan_mgmt.dba_plans`.
1. Chiama `apg_plan_mgmt.validate_plans('update_plan_hash')` per aggiornare il valore `plan_hash` nella tabella dei piani.
1. Ripeti i passaggi 2-3 per tutti i database con la funzionalità di gestione dei piani di query abilitata contenenti voci nella vista `apg_plan_mgmt.dba_plans`.
Per ulteriori informazioni su questi parametri, consulta [Documentazione di riferimento dei parametri per la gestione del piano di query Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Parameters.md).
## Acquisizione dei piani per la partizione delle tabelle
Nella funzionalità di gestione dei piani di query, i vari piani si differenziano per il rispettivo valore `plan_hash`. Per capire come il valore `plan_hash` cambia, devi prima familiarizzare con un tipo simile di piani.
La combinazione di metodi di accesso, nomi di indice con rimozione di cifre e nomi di partizione con rimozione di cifre, accumulati a livello di nodo Append deve essere costante affinché i piani siano considerati uguali. Le partizioni specifiche a cui si accede nei piani non sono significative. Nell'esempio seguente, viene creata una tabella `tbl_a` con 4 partizioni.
```
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
```
I piani seguenti sono considerati uguali perché viene utilizzato un unico metodo di scansione di `tbl_a` indipendentemente dal numero di partizioni cercate dalla query.
```
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)
```
Anche i seguenti 3 piani sono considerati uguali perché, a livello padre, i metodi di accesso, i nomi degli indici con rimozione di cifre e i nomi delle partizioni con rimozione di cifre sono `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)
```
Indipendentemente dalla diversità a livello di ordine e numero di occorrenze nelle partizioni secondarie, i metodi di accesso, i nomi degli indici con rimozione di cifre e i nomi delle partizioni con rimozione di cifre sono costanti a livello padre per ciascuno dei piani precedenti.
Tuttavia, i piani sarebbero considerati diversi se fosse soddisfatta una delle seguenti condizioni:
+ Nel piano viene utilizzato qualsiasi metodo di accesso aggiuntivo.
```
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)
```
+ Nessuno dei metodi di accesso del piano non viene più utilizzato.
```
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)
```
+ L'indice associato a un metodo di indice viene modificato.
```
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)
```
## Applicazione di un piano di partizione delle tabelle
I piani approvati per le tabelle partizionate vengono applicati con la corrispondenza a livello di posizione. I piani non sono specifici delle partizioni e possono essere applicati a partizioni diverse dai piani a cui si fa riferimento nella query originale. I piani possono essere applicati anche per le richieste che accedono a un numero di partizioni diverso rispetto alla struttura originale approvata.
Ad esempio, se la struttura approvata si riferisce al seguente piano:
```
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)
```
Questo piano può pertanto essere applicato anche alle query SQL che fanno riferimento a 2, 4 o più partizioni. I possibili piani che potrebbero derivare da questi scenari per l'accesso a 2 e 4 partizioni sono:
```
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)
```
Prendi in considerazione un altro piano approvato con metodi di accesso diversi per ogni partizione:
```
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)
```
In questo caso, qualsiasi piano che esegue letture da due partizioni non viene applicato. A meno che tutte le combinazioni (metodo di accesso, nome di indice) del piano approvato non siano utilizzabili, il piano non può essere applicato. Ad esempio, i seguenti piani hanno hash diversi e il piano approvato non può essere applicato in questi casi:
```
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)
```
## Convenzione di denominazione
Affinché QPM applichi un piano con tabelle partizionate dichiarative, è necessario seguire regole di denominazione specifiche per le tabelle principale, le partizioni di tabella e gli indici:
+ **Nomi delle tabelle principale**: questi nomi devono differire per lettere o caratteri speciali e non solo per cifre. Ad esempio, tA, tB e tC sono nomi accettabili per tabelle padre distinte, mentre t1, t2 e t3 non lo sono.
+ **Nomi delle singole tabelle delle partizioni**: le partizioni della stessa tabella principale devono differire l’una dall’altra solo per le cifre. Ad esempio, i nomi di partizione accettabili per tA potrebbero essere tA1, tA2 o T1a, T2a o anche un numero maggiore di cifre.
Eventuali altre differenze (lettere, caratteri speciali) non garantiranno l'applicazione del piano.
+ **Nomi degli indici**: nella gerarchia delle tabelle delle partizioni, assicurarsi che tutti gli indici abbiano nomi univoci. Ciò significa che le parti non numeriche dei nomi devono essere diverse. Ad esempio, se si dispone di una tabella partizionata denominata `tA` con un indice denominato `tA_col1_idx1`, non è possibile avere un altro indice denominato `tA_col1_idx2`. Tuttavia, è possibile avere un indice denominato `tA_a_col1_idx2` perché la parte non numerica del nome è univoca. Questa regola si applica agli indici creati sia nella tabella principale che nelle singole tabelle delle partizioni.
La mancata conformità alle convenzioni di denominazione sopra citate può comportare la mancata applicazione dei piani approvati. L'esempio seguente illustra tale mancata applicazione:
```
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)
```
Anche se i due piani possono apparire identici, i relativi valori `Plan Hash` sono diversi a causa dei nomi delle tabelle secondarie. I nomi delle tabelle variano in base ai caratteri alfabetici anziché alle sole cifre, il che comporta un errore di applicazione.