Описание

Данная команда отображает план выполнения, который Digital Q.DataBase планировщик формирует для указанного оператора. План выполнения показывает, каким образом таблицы, на которые ссылается оператор, будут сканироваться — посредством обычного последовательного сканирования, сканирования индекса и т. д. — а если указано несколько таблиц — какие алгоритмы соединения будут использованы для объединения необходимых строк из каждой входной таблицы.

Наиболее важной частью вывода является оценочная стоимость выполнения оператора, представляющая собой предположение планировщика о том, сколько времени займет выполнение запроса (измеряется в условных единицах стоимости, которые традиционно приравниваются к операциям чтения дисковых страниц). Фактически отображаются два числа: затраты на запуск до момента получения первой строки и общие затраты на получение всех строк. Для большинства запросов значение имеют общие затраты, но в таких контекстах, как подзапрос в EXISTS, планировщик выберет наименьшие затраты на запуск вместо наименьших общих затрат (так как исполнитель в любом случае остановится после получения одной строки). Кроме того, если количество возвращаемых строк ограничивается с помощью предложения LIMIT , планировщик выполняет соответствующую интерполяцию между стоимостными оценками в конечных точках, чтобы определить наиболее экономичный план.

Параметр ANALYZE инициирует фактическое выполнение оператора, а не только построение плана. В этом случае в отчет добавляется статистика фактического времени выполнения, включая общее время, затраченное в каждом узле плана (в миллисекундах), и общее количество строк, фактически возвращенных этим узлом. Это позволяет определить, насколько оценки планировщика близки к реальности.

BEGIN;
EXPLAIN ANALYZE ...;
ROLLBACK;

Параметры

Выводит

Результатом выполнения команды является текстовое описание плана, выбранного для оператор, опционально дополненное статистикой выполнения. Раздел 2.11.1 описывает предоставляемую информацию.

Примечания

Для того чтобы Digital Q.DataBase планировщик запросов мог принимать обоснованные решения при оптимизации запросов, pg_statistic данные должны быть актуальными для всех таблиц, участвующих в запросе. Как правило, демон autovacuum выполняет это автоматически. Но если содержимое таблицы недавно претерпело существенные изменения, может потребоваться ручное выполнение ANALYZE вместо того чтобы ждать, пока autovacuum обработает эти изменения.

Для измерения стоимости времени выполнения каждого узла в плане выполнения текущая реализация EXPLAIN ANALYZE вносит дополнительные накладные расходы на профилирование в процесс выполнения запроса. В результате выполнение EXPLAIN ANALYZE команды для запроса иногда может занимать значительно больше времени, чем обычное выполнение запроса. Величина накладных расходов зависит от характера запроса, а также от используемой платформы. Наихудший случай наблюдается для тех узлов плана, выполнение которых само по себе занимает очень мало времени, и на машинах с относительно медленными системными вызовами для получения времени суток.

Примеры

Чтобы просмотреть план простого запроса к таблице с одним integer столбцом и 10000 строками:

EXPLAIN SELECT * FROM foo;

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

Тот же запрос с использованием формата вывода JSON:

EXPLAIN (FORMAT JSON) SELECT * FROM foo;
           QUERY PLAN
--------------------------------
 [                             +
   {                           +
     "Plan": {                 +
       "Тип узла": "Seq Scan",+
       "Имя отношения": "foo", +
       "Псевдоним": "foo",         +
       "Затраты на запуск": 0.00,   +
       "Общие затраты": 155.00,   +
       "Строки плана": 10000,     +
       "Ширина плана": 4         +
     }                         +
   }                           +
 ]
(1 строка)

Если индекс существует и в запросе используется индексируемое WHERE условие, EXPLAIN может быть выведен другой план:

EXPLAIN SELECT * FROM foo WHERE i = 4;

                         ПЛАН ЗАПРОСА
--------------------------------------------------------------
 Index Scan using fi on foo  (cost=0.00..5.98 rows=1 width=4)
   Index Cond: (i = 4)
(2 строки)

Тот же запрос в формате YAML:

EXPLAIN (FORMAT YAML) SELECT * FROM foo WHERE i='4';
          QUERY PLAN
-------------------------------
 - Plan:                      +
     Тип узла: "Index Scan"  +
     Scan Direction: "Forward"+
     Index Name: "fi"         +
     Имя отношения: "foo"     +
     Псевдоним: "foo"             +
     Затраты на запуск: 0.00       +
     Общие затраты: 5.98         +
     Строки плана: 1             +
     Ширина плана: 4            +
     Условие индекса: "(i = 4)"
(1 строка)

Формат XML оставлен для самостоятельного изучения читателем.

Ниже представлен тот же план без вывода оценок затрат:

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

        QUERY PLAN
----------------------------
 Index Scan с использованием fi по foo
   Условие индекса: (i = 4)
(2 строки)

Ниже приведен пример плана выполнения для запроса с использованием агрегатной функции:

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

                             ПЛАН ЗАПРОСА
-------------------------------------------------------------------​--
 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)
         Условие индекса: (i < 10)
(3 строки)

Ниже приведен пример использования EXPLAIN EXECUTE для вывода плана выполнения подготовленного запроса:

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 loops=1)
   Ключ группировки: foo
   Batches: 1  Memory Usage: 24kB
   ->  Index Scan using test_pkey on test  (cost=0.29..10.27 rows=99 width=8) (actual time=0.009..0.025 rows=99 loops=1)
         Index Cond: ((id > 100) AND (id < 200))
 Planning Time: 0.244 ms
 Execution Time: 0.073 ms
(7 rows)

Разумеется, конкретные значения, приведенные здесь, зависят от фактического содержимого соответствующих таблиц. Также следует учитывать, что эти значения и даже выбранная стратегия выполнения запроса могут меняться между Digital Q.DataBase версиями вследствие улучшений планировщика. Кроме того, ANALYZE команда использует случайную выборку для оценки статистических данных; следовательно, оценки стоимости могут измениться после очередного запуска ANALYZE, даже если фактическое распределение данных в таблице не изменилось.

Обратите внимание, что в предыдущем примере был показан «индивидуальный» план для конкретных значений параметров, указанных в EXECUTE. Также может возникнуть необходимость просмотреть общий план для параметризованного запроса, что можно сделать с помощью 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)
   Ключ группировки: 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 строки)

В данном случае парсер корректно определил, что $1 и $2 должны иметь тот же тип данных, что и id, поэтому отсутствие информации о типах параметров в PREPARE не создало проблем. В других случаях может потребоваться явно указать типы для символов параметров, что можно сделать с помощью приведения типов, например:

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

Совместимость

В стандарте SQL оператор EXPLAIN не определен.

Следующий синтаксис использовался до Digital Q.DataBase версии 9.0 и до сих пор поддерживается:

EXPLAIN [ ANALYZE ] [ VERBOSE ] оператор

Обратите внимание, что в данном синтаксисе параметры должны быть указаны строго в приведенном порядке.

См. также