Руководство по созданию эффективных запросов

Рис. 4.2 

Графическое представление простого плана выполнения (лис тинг 4.4)
Для более сложных запросов графическое представление плана выполне-
ния может быть менее полезным – взгляните на представление плана вы-
полнения для лис тинга 4.1 на рис. 4.3.
Рис. 4.3 

Графическое представление плана выполнения для лис тинга 4.1
В таких случаях более компактное текстовое представление, как на рис. 4.4, 
оказывается полезнее.
Теперь вернемся к фактическому выводу команды 
EXPLAIN
, изображенному 
на рис. 4.1. Он показывает каждый узел дерева в отдельной строке, начина-
ющейся с символа 
->
, а глубина узла представлена отступом. Поддеревья 
помещаются после своего родительского узла. Некоторые операции пред-
ставлены двумя строками.
Выполнение плана начинается с листьев и заканчивается у корня. Это зна-
чит, что операция, которая выполняется первой, находится в строке с наи-
большим отступом. Конечно, план может содержать несколько листовых 
узлов, которые выполняются независимо. Как только операция создает вы-
ходную строку, эта строка передается следующей операции. Таким образом, 
не нужно хранить промежуточные результаты между операциями.
На рис. 4.1 выполнение начинается с последней строки, а таблица 
flight
читается с помощью индекса по столбцу 
departure_airport
. Поскольку к таб-
лице применено несколько фильтров, а индексом поддерживается только 
одно из условий фильтрации, PostgreSQL выполняет операцию
index
bitmap

---

Планы выполнения 

61
scan
(описанную в главе 2). Движок обращается к индексу и составляет би-
товую карту блоков, которые могут содержать необходимые записи. Затем 
он считывает фактические блоки из базы данных с помощью операции 
bit-
map
heap
scan
, и для каждой записи, извлеченной из базы данных, повторно 
проверяет (
recheck
), что найденные в индексе строки являются текущими, 
и применяет фильтрацию (
filter
) для дополнительных условий по столбцам 
arrival_airport
и 
schedule_departure
, для которых у нас нет индексов.
Рис. 4.4 

Альтернативное текстовое представление того же плана выполнения
Результат соединяется с таблицей 
booking_leg
. PostgreSQL использует по-
следовательное сканирование для доступа к этой таблице и алгоритм соеди-
нения хешированием по условию 
bl.flight_id
=
f.flight_id
.
Затем таблица 
passenger
читается последовательным сканированием (по-
скольку на ней нет никаких индексов), и снова используется алгоритм со-
единения хешированием по условию 
p.booking_id
=
bl.booking_id
.
Последняя выполняемая операция – группировка и вычисление агре-
гатной функции 
sum
. После сортировки выясняется, что критериям поиска 
удовлетворяет только один рейс. Таким образом, нет необходимости ис-
пользовать какие-либо алгоритмы группировки, и выполняется подсчет всех 
пассажиров на найденном рейсе.
В следующем разделе рассматривается, что еще можно почерпнуть из пла-
на выполнения и почему это важно.