

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à.

# Utilizzo dei piani gestiti per Aurora PostgreSQL
<a name="AuroraPostgreSQL.Optimize.UsePlans"></a>

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
<a name="AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans"></a>

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.
<a name="AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans"></a>

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). 