Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
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à.
# EXPLAIN
Mostra il piano di esecuzione per l'istruzione di una query senza eseguire la query. Per informazioni sul flusso di lavoro di analisi delle query, consulta [Flusso di lavoro dell'analisi di query](c-query-analysis-process.md).
## Sintassi
```
EXPLAIN [ VERBOSE ] query
```
## Parameters
VERBOSE
Visualizza il piano di query completo anziché solo un riepilogo.
*query*
Istruzione di query da spiegare. La query può essere un'istruzione SELECT, INSERT, CREATE TABLE AS, UPDATE o DELETE.
## Note per l'utilizzo
Le prestazioni di EXPLAIN sono talvolta influenzate dal tempo necessario per creare le tabelle temporanee. Ad esempio, una query che utilizza l'ottimizzazione dell'espressione secondaria comune richiede che vengano create e analizzate le tabelle temporanee per restituire l'output di EXPLAIN. Il piano di query dipende dallo schema e dalle statistiche delle tabelle temporanee. Pertanto, il comando EXPLAIN per questo tipo di query potrebbe impiegare più tempo del previsto.
Puoi utilizzare EXPLAIN solo per i seguenti comandi:
+ SELECT
+ SELECT INTO
+ CREATE TABLE AS
+ INSERT
+ UPDATE
+ DELETE
Il comando EXPLAIN avrà esito negativo se lo si utilizza per altri comandi SQL, ad esempio operazioni di database o DDL (Data Definition Language).
I costi unitari relativi all'output EXPLAIN vengono utilizzati da Amazon Redshift per scegliere un piano di query. Amazon Redshift confronta le dimensioni delle varie stime delle risorse per determinare il piano.
## Pianificazione di query e fasi di esecuzione
Il piano di esecuzione per una istruzione di query Amazon Redshift specifica suddivide l'esecuzione e il calcolo di una query in una sequenza discreta di fasi e operazioni di tabella che alla fine produce un set di risultati finali per la query. Per informazioni sulla pianificazione di query, consultare [Elaborazione query](c-query-processing.md).
La seguente tabella fornisce un riepilogo delle fasi che Amazon Redshift può utilizzare nello sviluppo di un piano di esecuzione per qualsiasi query inviata dall'utente per l'esecuzione.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/r_EXPLAIN.html)
## Utilizzo di EXPLAIN per RLS
Se una query contiene una tabella soggetta a politiche di sicurezza a livello di riga (RLS), EXPLAIN visualizza un nodo RLS speciale. SecureScan Amazon Redshift registra anche lo stesso tipo di nodo nella tabella di sistema STL\$1EXPLAIN. EXPLAIN non rivela il predicato RLS che si applica a dim\$1tbl. Il tipo di SecureScan nodo RLS serve da indicatore del fatto che il piano di esecuzione contiene operazioni aggiuntive invisibili all'utente corrente.
L'esempio seguente illustra un nodo RLS SecureScan .
```
EXPLAIN
SELECT D.cint
FROM fact_tbl F INNER JOIN dim_tbl D ON F.k_dim = D.k
WHERE F.k_dim / 10 > 0;
QUERY PLAN
------------------------------------------------------------------------
XN Hash Join DS_DIST_ALL_NONE (cost=0.08..0.25 rows=1 width=4)
Hash Cond: ("outer".k_dim = "inner"."k")
-> *XN* *RLS SecureScan f (cost=0.00..0.14 rows=2 width=4)*
Filter: ((k_dim / 10) > 0)
-> XN Hash (cost=0.07..0.07 rows=2 width=8)
-> XN Seq Scan on dim_tbl d (cost=0.00..0.07 rows=2 width=8)
Filter: (("k" / 10) > 0)
```
Per consentire un'analisi completa dei piani di query soggetti a RLS, Amazon Redshift offre le autorizzazioni di sistema EXPLAIN RLS. Gli utenti a cui è stata concessa questa autorizzazione possono esaminare piani di query completi che includono anche predicati RLS.
L'esempio seguente illustra un Seq Scan aggiuntivo sotto il SecureScan nodo RLS che include anche il predicato della policy RLS (k\$1dim > 1).
```
EXPLAIN SELECT D.cint
FROM fact_tbl F INNER JOIN dim_tbl D ON F.k_dim = D.k
WHERE F.k_dim / 10 > 0;
QUERY PLAN
---------------------------------------------------------------------------------
XN Hash Join DS_DIST_ALL_NONE (cost=0.08..0.25 rows=1 width=4)
Hash Cond: ("outer".k_dim = "inner"."k")
*-> XN RLS SecureScan f (cost=0.00..0.14 rows=2 width=4)
Filter: ((k_dim / 10) > 0)*
-> *XN* *Seq Scan on fact_tbl rls_table (cost=0.00..0.06 rows=5 width=8)
Filter: (k_dim > 1)*
-> XN Hash (cost=0.07..0.07 rows=2 width=8)
-> XN Seq Scan on dim_tbl d (cost=0.00..0.07 rows=2 width=8)
Filter: (("k" / 10) > 0)
```
Sebbene l'autorizzazione EXPLAIN RLS sia concessa a un utente, Amazon Redshift registra il piano di query completo, inclusi i predicati RLS, nella tabella di sistema STL\$1EXPLAIN. Le query che vengono eseguite mentre questa autorizzazione non è concessa verranno registrate senza interni RLS. La concessione o la rimozione dell'autorizzazione EXPLAIN RLS non modificherà ciò che Amazon Redshift ha registrato su STL\$1EXPLAIN per le query precedenti.
### Relazioni Redshift protette da AWS Lake Formation-RLS
L'esempio seguente illustra un SecureScan nodo LF, che è possibile utilizzare per visualizzare le relazioni Lake Formation-RLS.
```
EXPLAIN
SELECT *
FROM lf_db.public.t_share
WHERE a > 1;
QUERY PLAN
---------------------------------------------------------------
XN LF SecureScan t_share (cost=0.00..0.02 rows=2 width=11)
(2 rows)
```
## Esempi
**Nota**
Per questi esempi, l'output di esempio potrebbe variare a seconda della configurazione di Amazon Redshift.
L'esempio seguente restituisce il piano di query per una query che seleziona EVENTID, EVENTNAME, VENUEID e VENUENAME dalle tabelle EVENT e VENUE:
```
explain
select eventid, eventname, event.venueid, venuename
from event, venue
where event.venueid = venue.venueid;
```
```
QUERY PLAN
--------------------------------------------------------------------------
XN Hash Join DS_DIST_OUTER (cost=2.52..58653620.93 rows=8712 width=43)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=23)
-> XN Hash (cost=2.02..2.02 rows=202 width=22)
-> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=22)
(5 rows)
```
L'esempio seguente restituisce il piano di query per la stessa query con output dettagliato:
```
explain verbose
select eventid, eventname, event.venueid, venuename
from event, venue
where event.venueid = venue.venueid;
```
```
QUERY PLAN
--------------------------------------------------------------------------
{HASHJOIN
:startup_cost 2.52
:total_cost 58653620.93
:plan_rows 8712
:plan_width 43
:best_pathkeys <>
:dist_info DS_DIST_OUTER
:dist_info.dist_keys (
TARGETENTRY
{
VAR
:varno 2
:varattno 1
...
XN Hash Join DS_DIST_OUTER (cost=2.52..58653620.93 rows=8712 width=43)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=23)
-> XN Hash (cost=2.02..2.02 rows=202 width=22)
-> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=22)
(519 rows)
```
L'esempio seguente restituisce il piano di query per un'istruzione CREATE TABLE AS (CTAS):
```
explain create table venue_nonulls as
select * from venue
where venueseats is not null;
QUERY PLAN
-----------------------------------------------------------
XN Seq Scan on venue (cost=0.00..2.02 rows=187 width=45)
Filter: (venueseats IS NOT NULL)
(2 rows)
```