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à.
# Hop della coda di query WLM
Con Amazon Redshift puoi gestire la simultaneità dei carichi di lavoro e l’allocazione delle risorse abilitando l’hop della coda di query WLM. Questa funzionalità consente alle query di “saltare” temporaneamente da una coda assegnata a una coda con priorità più elevata quando le risorse sono disponibili, migliorando le prestazioni complessive delle query e l’utilizzo del sistema. Nelle sezioni seguenti vengono fornite indicazioni dettagliate sulla configurazione e sull’utilizzo dell’hop della coda di query WLM in Amazon Redshift.
Una query può essere saltata a causa di un [timeout WLM](cm-c-defining-query-queues.md#wlm-timeout) o un'[operazione hop (QMR) di monitoraggio della query](cm-c-wlm-query-monitoring-rules.md#cm-c-wlm-defining-query-monitoring-rules). Puoi saltare le query solo in una configurazione WLM manuale.
Quando una query viene saltata, WLM tenta di indirizzare la query alla successiva coda corrispondente in base alle [regole di assegnazione delle code WLM](cm-c-wlm-queue-assignment-rules.md). Se la query non corrisponde ad alcuna altra definizione di coda, la query viene annullata. Non viene assegnata alla coda predefinita.
## Operazioni relative al timeout WLM
La tabella seguente riepiloga il comportamento dei diversi tipi di query con un timeout WLM.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/wlm-queue-hopping.html)
## Hop della coda di timeout WLM
WLM salta i seguenti tipi di query quando generano un timeout:
+ Query di sola lettura, come le istruzioni SELECT, che si trovano nello stato WLM `running`. Per trovare lo stato WLM di una query, consultare la colonna STATE della tabella di sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md).
+ Istruzioni CREATE TABLE AS (CTAS). L'hop della coda WLM supporta le istruzioni CTAS definite dall'utente e generate dal sistema.
+ Istruzioni SELECT INTO.
Le query che non sono soggette al timeout WLM continuano a essere eseguite nella coda originale fino al completamento. I seguenti tipi di query non sono soggetti al timeout WLM:
+ Istruzioni COPY
+ Operazioni di manutenzione come ALTER, ANALYZE e VACUUM
+ Query di sola lettura, come le istruzioni SELECT, che sono nello stato WLM `returning`. Per trovare lo stato WLM di una query, consultare la colonna STATE della tabella di sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md).
Le query che non sono idonee per l'hop da un timeout WLM vengono annullate quando generano il timeout. I seguenti tipi di query non sono idonei per l'hop da un timeout WLM:
+ Istruzioni INSERT, UPDATE e DELETE
+ Istruzioni UNLOAD
+ Funzioni definite dall'utente () UDFs
## Query riavviate e riassegnate per timeout WLM
Quando una query viene saltata e non viene trovata alcuna coda corrispondente, la query viene annullata.
Quando una query viene saltata e viene trovata una coda corrispondente, WLM tenta di riassegnare la query alla nuova coda. Se una query non può essere riassegnata, viene riavviata nella nuova coda, come descritto di seguito.
Una query viene riassegnata solo se tutte le seguenti considerazioni sono vere:
+ Viene trovata una coda corrispondente.
+ La nuova coda ha abbastanza slot liberi per eseguire la query. Una query potrebbe richiedere più slot se il parametro [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) è stato impostato su un valore superiore a 1.
+ La nuova coda ha almeno la stessa memoria disponibile utilizzata attualmente dalla query.
Se la query viene riassegnata, la query continua a essere eseguita nella nuova coda. I risultati intermedi vengono conservati, per cui l'effetto sul tempo totale di esecuzione è minimo.
Se la query non può essere riassegnata, la query viene annullata e riavviata nella nuova coda. I risultati intermedi sono eliminati. La query attende nella coda, quindi inizia a essere eseguita quando sono disponibili sufficienti slot.
## Operazioni di hop QMR
La tabella seguente riepiloga il comportamento dei diversi tipi di query con un'operazione hop QMR.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/wlm-queue-hopping.html)
Per scoprire se una query che è stata saltata da QMR è stata riassegnata, riavviata o annullata, eseguire una query sulla tabella di log del sistema [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md).
## Query riavviate e riassegnate per operazione hop QMR
Quando una query viene saltata e non viene trovata alcuna coda corrispondente, la query viene annullata.
Quando una query viene saltata e viene trovata una coda corrispondente, WLM tenta di riassegnare la query alla nuova coda. Se una query non può essere riassegnata, viene riavviata nella nuova coda o continua l'esecuzione nella coda originale, come descritto di seguito.
Una query viene riassegnata solo se tutte le seguenti considerazioni sono vere:
+ Viene trovata una coda corrispondente.
+ La nuova coda ha abbastanza slot liberi per eseguire la query. Una query potrebbe richiedere più slot se il parametro [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) è stato impostato su un valore superiore a 1.
+ La nuova coda ha almeno la stessa memoria disponibile utilizzata attualmente dalla query.
Se la query viene riassegnata, la query continua a essere eseguita nella nuova coda. I risultati intermedi vengono conservati, per cui l'effetto sul tempo totale di esecuzione è minimo.
Se una query non può essere riassegnata, la query viene riavviata o continua l'esecuzione nella coda originale. Se la query viene riavviata, la query viene annullata e riavviata nella nuova coda. I risultati intermedi sono eliminati. La query attende nella coda, quindi inizia l'esecuzione quando sono disponibili sufficienti slot.