Descripción

Este comando muestra el plan de ejecución que el planificador de PostgreSQL genera para la sentencia suministrada. El plan de ejecución muestra cómo se escanearán la(s) tabla(s) a la(s) que hace referencia la sentencia — mediante escaneo secuencial simple, escaneo de índice, etc. — y, si se hace referencia a varias tablas, qué algoritmos de unión (join) se utilizarán para reunir las filas requeridas de cada tabla de entrada.

La parte más crítica de la pantalla es el costo estimado de ejecución de la sentencia, que es la estimación del planificador sobre cuánto tiempo tardará en ejecutarse la sentencia (medido en unidades de costo que son arbitrarias, pero que convencionalmente significan lecturas de páginas de disco). En realidad, se muestran dos números: el costo de inicio (start-up cost) antes de que se pueda devolver la primera fila, y el costo total para devolver todas las filas. Para la mayoría de las consultas, lo que importa es el costo total, pero en contextos como una subconsulta en EXISTS, el planificador elegirá el costo de inicio más pequeño en lugar del costo total más pequeño (ya que el ejecutor se detendrá después de obtener una fila, de todos modos). Además, si limitas el número de filas a devolver con una cláusula LIMIT, el planificador realiza una interpolación adecuada entre los costos de los extremos para estimar qué plan es realmente el más barato.

La opción ANALYZE hace que la sentencia se ejecute realmente, no solo se planifique. Luego, se añaden estadísticas de tiempo de ejecución reales a la pantalla, incluyendo el tiempo total transcurrido en cada nodo del plan (en milisegundos) y el número total de filas que realmente devolvió. Esto es útil para ver si las estimaciones del planificador son cercanas a la realidad.

BEGIN;
EXPLAIN ANALYZE ...;
ROLLBACK;

Parámetros

Salidas

El resultado del comando es una descripción textual del plan seleccionado para la sentencia, opcionalmente anotada con estadísticas de ejecución. La Section 14.1 describe la información proporcionada.

Notas

Para permitir que el planificador de consultas de PostgreSQL tome decisiones razonablemente informadas al optimizar las consultas, los datos de pg_statistic deben estar actualizados para todas las tablas utilizadas en la consulta. Normalmente, el demonio de autovacuum se encargará de ello automáticamente. Pero si una tabla ha tenido cambios sustanciales recientemente en su contenido, es posible que debas realizar un ANALYZE manual en lugar de esperar a que autovacuum se ponga al día con los cambios.

Para medir el costo en tiempo de ejecución de cada nodo en el plan de ejecución, la implementación actual de EXPLAIN ANALYZE añade una sobrecarga de análisis de rendimiento (profiling) a la ejecución de la consulta. Como resultado, ejecutar EXPLAIN ANALYZE en una consulta a veces puede tomar significativamente más tiempo que ejecutar la consulta normalmente. La cantidad de sobrecarga depende de la naturaleza de la consulta, así como de la plataforma utilizada. El peor caso ocurre para los nodos del plan que en sí mismos requieren muy poco tiempo por ejecución, y en máquinas que tienen llamadas del sistema operativo relativamente lentas para obtener la hora del día.

Ejemplos

Para mostrar el plan de una consulta simple en una tabla con una sola columna de tipo integer y 10000 filas:

EXPLAIN SELECT * FROM foo;

                       QUERY PLAN
 ---------------------------------------------------------
  Seq Scan on foo  (cost=0.00..155.00 rows=10000 width=4)
(1 row)

Aquí está la misma consulta, con formato de salida JSON:

EXPLAIN (FORMAT JSON) SELECT * FROM foo;
           QUERY PLAN
--------------------------------
 [                             +
   {                           +
     "Plan": {                 +
       "Node Type": "Seq Scan",+
       "Relation Name": "foo", +
       "Alias": "foo",         +
       "Startup Cost": 0.00,   +
       "Total Cost": 155.00,   +
       "Plan Rows": 10000,     +
       "Plan Width": 4         +
     }                         +
   }                           +
 ]
(1 row)

Si hay un índice y usamos una consulta con una condición WHERE indexable, EXPLAIN podría mostrar un plan diferente:

EXPLAIN SELECT * FROM foo WHERE i = 4;

                          QUERY PLAN
--------------------------------------------------------------
  Index Scan using fi on foo  (cost=0.00..5.98 rows=1 width=4)
    Index Cond: (i = 4)
(2 rows)

Aquí está la misma consulta, pero en formato YAML:

EXPLAIN (FORMAT YAML) SELECT * FROM foo WHERE i='4';
          QUERY PLAN
-------------------------------
 - Plan:                      +
     Node Type: "Index Scan"  +
     Scan Direction: "Forward"+
     Index Name: "fi"         +
     Relation Name: "foo"     +
     Alias: "foo"             +
     Startup Cost: 0.00       +
     Total Cost: 5.98         +
     Plan Rows: 1             +
     Plan Width: 4            +
     Index Cond: "(i = 4)"
(1 row)

El formato XML se deja como ejercicio para el lector.

Aquí está el mismo plan con las estimaciones de costo suprimidas:

EXPLAIN (COSTS FALSE) SELECT * FROM foo WHERE i = 4;

        QUERY PLAN
----------------------------
 Index Scan using fi on foo
   Index Cond: (i = 4)
(2 rows)

Aquí está un ejemplo de un plan de consulta para una consulta que utiliza una función de agregación:

EXPLAIN SELECT sum(i) FROM foo WHERE i < 10;

                              QUERY PLAN
-------------------------------------------------------------------​--
 Aggregate  (cost=23.93..23.93 rows=1 width=4)
   ->  Index Scan using fi on foo  (cost=0.00..23.92 rows=6 width=4)
         Index Cond: (i < 10)
(3 rows)

Aquí está un ejemplo del uso de EXPLAIN EXECUTE para mostrar el plan de ejecución de una consulta preparada:

PREPARE query(int, int) AS SELECT sum(bar) FROM test
    WHERE id > $1 AND id < $2
    GROUP BY foo;

EXPLAIN ANALYZE EXECUTE query(100, 200);

                                                       QUERY PLAN
-------------------------------------------------------------------​------------------------------------------------------
 HashAggregate  (cost=10.77..10.87 rows=10 width=12) (actual time=0.043..0.044 rows=10.00 loops=1)
   Group Key: foo
   Batches: 1  Memory Usage: 24kB
   Buffers: shared hit=4
   ->  Index Scan using test_pkey on test  (cost=0.29..10.27 rows=99 width=8) (actual time=0.009..0.025 rows=99.00 loops=1)
         Index Cond: ((id > 100) AND (id < 200))
         Index Searches: 1
         Buffers: shared hit=4
 Planning Time: 0.244 ms
 Execution Time: 0.073 ms
(10 rows)

Por supuesto, los números específicos que se muestran aquí dependen del contenido real de las tablas involucradas. También ten en cuenta que los números, e incluso la estrategia de consulta seleccionada, pueden variar entre las versiones de PostgreSQL debido a las mejoras del planificador. Además, el comando ANALYZE utiliza un muestreo aleatorio para estimar las estadísticas de los datos; por lo tanto, es posible que las estimaciones de costo cambien después de una nueva ejecución de ANALYZE, incluso si la distribución real de los datos en la tabla no ha cambiado.

Ten en cuenta que el ejemplo anterior mostró un plan “personalizado” (custom plan) para los valores de parámetros específicos dados en EXECUTE. También podríamos desear ver el plan genérico para una consulta parametrizada, lo cual se puede hacer con GENERIC_PLAN:

EXPLAIN (GENERIC_PLAN)
  SELECT sum(bar) FROM test
    WHERE id > $1 AND id < $2
    GROUP BY foo;

                                  QUERY PLAN
-------------------------------------------------------------------​------------
 HashAggregate  (cost=26.79..26.89 rows=10 width=12)
   Group Key: foo
   ->  Index Scan using test_pkey on test  (cost=0.29..24.29 rows=500 width=8)
         Index Cond: ((id > $1) AND (id < $2))
(4 rows)

En este caso, el analizador (parser) infirió correctamente que $1 y $2 debían tener el mismo tipo de datos que id, por lo que la falta de información sobre el tipo de parámetro de PREPARE no fue un problema. En otros casos, puede ser necesario especificar explícitamente los tipos para los símbolos de los parámetros, lo cual se puede hacer mediante una conversión de tipo (casting), por ejemplo:

EXPLAIN (GENERIC_PLAN)
  SELECT sum(bar) FROM test
    WHERE id > $1::integer AND id < $2::integer
    GROUP BY foo;

Compatibilidad

No hay ninguna sentencia EXPLAIN definida en el estándar SQL.

La siguiente sintaxis se utilizaba antes de la versión 9.0 de PostgreSQL y todavía se admite:

EXPLAIN [ ANALYZE ] [ VERBOSE ] sentencia

Ten en cuenta que en esta sintaxis, las opciones deben especificarse exactamente en el orden mostrado.

Véase también