SET enable_mergejoin = on

10.4. Управление планировщиком
Повторим предыдущий запрос с опцией ANALYZE.
EXPLAIN ANALYZE
SELECT t.ticket_no,
t.passenger_name,
tf.flight_id,
tf.amount
FROM tickets t
JOIN ticket_flights tf ON t.ticket_no = tf.ticket_no
ORDER BY t.ticket_no;
QUERY PLAN
-----------------------------------------------------------------
Merge Join (cost=1.51..98276.90 rows=1045726 width=40)
(actual time=0.087..10642.643 rows=1045726 loops=1)
Merge Cond: (t.ticket_no = tf.ticket_no)
-> Index Scan using tickets_pkey on tickets t
(cost=0.42..17230.42 rows=366733 width=30)
(actual time=0.031..762.460 rows=366733 loops=1)
-> Index Scan using ticket_flights_pkey on ticket_flights tf
(cost=0.42..67058.74 rows=1045726 width=24)
(actual time=0.006..7743.705 rows=1045726 loops=1)
Planning time: 122.347 ms
Execution time: 10948.791 ms
(6 строк)
Фактические затраты времени измеряются в миллисекундах, а оценки стоимости —
в условных единицах, поэтому плановые оценки и фактические затраты совпасть не
могут. Важнее обратить внимание на то, насколько точно планировщик оценил число
обрабатываемых строк, а также на фактическое число повторений того или иного уз-
ла дерева плана — это параметр loops. В данном запросе каждый узел плана был
выполнен ровно один раз, поскольку выбор строк из обоих соединяемых наборов
производился по индексу, поэтому достаточно одного прохода по каждому набору.
Число выбираемых строк было оценено точно, поскольку таблицы связаны по внеш-
нему ключу, и в выборку включаются все их строки (нет предложения WHERE).
Кроме времени выполнения запроса выводится также и время формирования плана.
Необходимо учитывать, что фактические затраты времени на разных компьютерах
будут различаться. Будет другим и фактическое время при повторном выполнении
запроса на одном и том же компьютере, поскольку и в СУБД, и в операционной си-
стеме используются буферизация и кэширование, а также с течением времени может
307

жүктеу/скачать 1.88 Mb.

Достарыңызбен бөлісу: