Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la [publicación del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
# EXPLAIN
Muestra el plan de ejecución de una instrucción de consulta sin ejecutar la consulta. Para obtener información sobre el flujo de trabajo del análisis de consultas, consulte [Flujo de trabajo de análisis de consultas](c-query-analysis-process.md).
## Sintaxis
```
EXPLAIN [ VERBOSE ] query
```
## Parameters
VERBOSE
Muestra el plan de consulta completo en lugar de solo un resumen.
*query*
Instrucción de consulta que se explicará. La consulta puede ser una instrucción SELECT, INSERT, CREATE TABLE AS, UPDATE o DELETE.
## Notas de uso
El rendimiento de EXPLAIN a menudo se ve afectado por el tiempo que lleva crear tablas temporales. Por ejemplo, una consulta que usa la optimización de subexpresión común requiere que se creen y analicen tablas temporales para devolver el resultado de EXPLAIN. El plan de consulta depende del esquema y las estadísticas de las tablas temporales. Por lo tanto, el comando EXPLAIN para este tipo de consulta puede tardar más tiempo en ejecutarse que lo esperado.
Puede usar EXPLAIN solo para los siguientes comandos:
+ SELECT
+ SELECT INTO
+ CREATE TABLE AS
+ INSERT
+ UPDATE
+ DELETE
El comando EXPLAIN producirá un error si lo utiliza para otros comandos SQL, como operaciones de base de datos o lenguaje de definición de datos (DDL).
Amazon Redshift utiliza los costos unitarios relativos de los resultados de EXPLAIN para elegir un plan de consultas. Amazon Redshift compara los tamaños de varias estimaciones de recursos para determinar el plan.
## Pasos de planificación y ejecución de consultas
El plan de ejecución para una instrucción de consulta de Amazon Redshift específica desglosa la ejecución y el cálculo de una consulta en una secuencia discreta de operaciones de tabla y pasos que eventualmente producen un conjunto de resultados finales para la consulta. Para obtener información acerca de la planificación de consultas, consulte [Procesamiento de consultas](c-query-processing.md).
La siguiente tabla proporciona un resumen de los pasos que Amazon Redshift puede utilizar con objeto de desarrollar un plan de ejecución para cualquier consulta que un usuario envíe para su ejecución.
[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/redshift/latest/dg/r_EXPLAIN.html)
## Uso de EXPLAIN para RLS
Si una consulta contiene una tabla que está sujeta a políticas de seguridad de la fila (RLS), EXPLAIN muestra un nodo especial SecureScan de RLS. Amazon Redshift también registra el mismo tipo de nodo en la tabla del sistema STL\_EXPLAIN. EXPLAIN no revela el predicado de RLS que se aplica a dim\_tbl. El tipo de nodo SecureScan de RLS sirve como indicador de que el plan de ejecución contiene operaciones adicionales que son invisibles para el usuario actual.
En el siguiente ejemplo, se ilustra un nodo SecureScan de RLS.
```
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 habilitar una investigación completa de los planes de consultas que están sujetos a RLS, Amazon Redshift ofrece los permisos del sistema EXPLAIN RLS. Los usuarios a los que se les haya otorgado este permiso pueden inspeccionar planes de consulta completos que también incluyan predicados de RLS.
En el siguiente ejemplo, se ilustra un análisis de secuencia adicional debajo del nodo SecureScan de RLS que también incluye el predicado de 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)
```
Mientras se concede el permiso EXPLAIN RLS a un usuario, Amazon Redshift registra el plan de consulta completo, incluidos los predicados de RLS, en la tabla del sistema STL\_EXPLAIN. Las consultas que se ejecutan mientras no se concede este permiso se registrarán sin los internos de RLS. La concesión o eliminación del permiso EXPLAIN RLS no cambiará lo que Amazon Redshift haya registrado en STL\_EXPLAIN para consultas anteriores.
### Relaciones de Redshift protegidas por RLS de AWS Lake Formation
En el siguiente ejemplo se ilustra un nodo LF SecureScan que puede utilizar para ver las relaciones entre Lake Formation y 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)
```
## Ejemplos
**nota**
Para estos ejemplos, la salida de ejemplo puede variar según la configuración de Amazon Redshift.
El siguiente ejemplo devuelve el plan de consulta para una consulta que selecciona EVENTID, EVENTNAME, VENUEID y VENUENAME de la tablas EVENT y 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)
```
El siguiente ejemplo devuelve el plan de consulta para la misma consulta con resultados más detallados:
```
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)
```
El siguiente ejemplo devuelve el plan de consulta para una instrucción 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)
```