O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # EXPLAIN Exibe o plano de execução para uma instrução de consulta sem executar a consulta. Para obter informações sobre o fluxo de trabalho de análise de consultas, consulte [Fluxo de trabalho da análise de consulta](c-query-analysis-process.md). ## Sintaxe ``` EXPLAIN [ VERBOSE ] query ``` ## Parâmetros VERBOSE Exibe o plano completo da consulta em vez de apenas um resumo. *query* Instrução da consulta a ser explicada. A consulta pode ser uma instrução SELECT, INSERT, CREATE TABLE AS, UPDATE ou DELETE. ## Observações de uso Às vezes, a performance do comando EXPLAIN é influenciado pelo tempo que ele leva para criar tabelas temporárias. Por exemplo, uma consulta que usa otimização comum de subexpressão requer tabelas temporárias para ser criada e analisada para retornar a saída EXPLAIN. O plano da consulta depende do esquema e das estatísticas das tabelas temporárias. Portanto, para esse tipo de consulta, o comando EXPLAIN pode levar mais tempo para ser executado que o esperado. Você pode usar EXPLAIN somente com os seguintes comandos: + SELECT + SELECT INTO + CREATE TABLE AS + INSERT + UPDATE + DELETE O comando EXPLAIN falhará se você o usar para outros comandos SQL, como data definition language (DDL) ou operações de banco de dados. Os custos unitários relativos da saída EXPLAIN são usados pelo Amazon Redshift para escolher um plano de consulta. O Amazon Redshift compara os tamanhos de várias estimativas de recursos para determinar o plano. ## Planejamento de consulta e etapas de execução O plano de execução de uma instrução de consulta específica do Amazon Redshift divide a execução e o cálculo de uma consulta em uma sequência diferente de etapas e operações de tabela que, por fim, produz um conjunto de resultados finais para a consulta. Para obter informações sobre consulta paralela, consulte [Processamento de consulta](c-query-processing.md). A tabela a seguir fornece um resumo de etapas que o Amazon Redshift pode usar para desenvolver um plano de execução para qualquer consulta enviada por um usuário para execução. [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/r_EXPLAIN.html) ## Utilização de EXPLAIN para RLS Se uma consulta contiver uma tabela sujeita às políticas de segurança no nível da linha (RLS), EXPLAIN exibirá um nó especial do RLS SecureScan. O Amazon Redshift também registra o mesmo tipo de nó na tabela do sistema STL\_EXPLAIN. EXPLAIN não revela o predicado RLS que se aplica a dim\_tbl. O tipo de nó RLS SecureScan serve como um indicador de que o plano de execução contém operações adicionais que são invisíveis para o usuário atual. O exemplo a seguir mostra um nó 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) ``` Para permitir a investigação completa dos planos de consulta sujeitos ao RLS, o Amazon Redshift oferece as permissões do sistema EXPLAIN RLS. Os usuários que receberam essa permissão podem inspecionar planos de consulta completos que também incluem predicados RLS. O exemplo a seguir ilustra uma Seq Scan adicional abaixo do nó RLS SecureScan que também inclui o predicado da política de RLS (k\_dim > 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) ``` Embora a permissão EXPLAIN RLS seja concedida a um usuário, o Amazon Redshift registra o plano de consulta completo, incluindo predicados RLS na tabela do sistema STL\_EXPLAIN. As consultas que forem executadas enquanto essa permissão não for concedida serão registradas sem os internos do RLS. Conceder ou remover a permissão EXPLAIN RLS não alterará o que o Amazon Redshift registrou em log no STL\_EXPLAIN para consultas anteriores. ### Relações do Redshift protegidas entre AWS Lake Formation e RLS O exemplo a seguir ilustra um nó LF SecureScan, que você pode usar para visualizar relações entre Lake Formation e 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) ``` ## Exemplos **nota** Para esses exemplos, o resultado da amostra pode variar dependendo da configuração do Amazon Redshift. O exemplo a seguir retorna o plano de consulta para uma consulta que seleciona EVENTID, EVENTNAME, VENUEID e VENUENAME das tabelas 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) ``` O exemplo a seguir retorna o plano de consulta para a mesma consulta com saída "verbose": ``` 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) ``` O exemplo a seguir retorna o plano de consulta para uma instrução 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) ```