Учебно-практическое пособие москва 2017 ббк
жүктеу/скачать 3,05 Mb. Pdf көрінісі
|
Язык SQL. Базовый курс
- Бұл бет үшін навигация:
- SET enable_mergejoin = on; SET Повторим предыдущий запрос с опцией 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 --------------------------------------------------------------- Sort (cost=226400.55..229014.87 rows=1045726 width=40) Sort Key: t.ticket_no -> Hash Join (cost=16824.49..64658.49 rows=1045726 width=40) Hash Cond: (tf.ticket_no = t.ticket_no) -> Seq Scan on ticket_flights tf (cost=0.00..18692.26 rows=1045726 width=24) , → -> Hash (cost=9733.33..9733.33 rows=366733 width=30) -> Seq Scan on tickets t (cost=0.00..9733.33 rows=366733 width=30) , → (7 строк) Теперь планировщик выбирает слияние хешированием. Полученные оценки стои- мости выполнения запроса будут значительно выше. При этом вывод результирую- щих строк начнется значительно позднее, чем при использовании метода соедине- ния слиянием. На это указывает значение параметра cost для верхнего узла дерева плана — cost=226400.55..229014.87. В команде EXPLAIN можно указать опцию ANALYZE, что позволит выполнить запрос и вывести на экран фактические затраты времени на выполнение запроса и число фактически выбранных строк. При этом, хотя запрос и выполняется, сами результи- рующие строки не выводятся. Сначала разрешим планировщику использовать метод соединения слиянием: SET enable_mergejoin = on; SET Повторим предыдущий запрос с опцией 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) 238 (actual time=0.006..7743.705 rows=1045726 loops=1) Planning time: 122.347 ms Execution time: 10948.791 ms (6 строк) Фактические затраты времени измеряются в миллисекундах, а оценки стоимости — в условных единицах, поэтому плановые оценки и фактические затраты совпасть не могут. Важнее обратить внимание на то, насколько точно планировщик оценил чис- ло обрабатываемых строк, а также на фактическое число повторений того или иного узла дерева плана — это параметр loops. В данном запросе каждый узел плана был вы- полнен ровно один раз, поскольку выбор строк из обоих соединяемых наборов про- изводился по индексу, поэтому достаточно одного прохода по каждому набору. Чис- ло выбираемых строк было оценено точно, поскольку таблицы связаны по внешнему ключу, и в выборку включаются все их строки (нет предложения WHERE). Кроме времени выполнения запроса выводится также и время формирования пла- на. Необходимо учитывать, что фактические затраты времени на разных компьютерах будут различаться. Будет другим и фактическое время при повторном выполнении запроса на одном и том же компьютере, поскольку и в СУБД, и в операционной си- стеме используются буферизация и кэширование, а также с течением времени может изменяться фактическая нагрузка на сервер. Поэтому время выполнения повторно- го запроса может оказаться значительно меньше, чем время выполнения первого, а время выполнения запроса в третий раз — немного больше, чем во второй. Если модифицировать запрос, добавив предложение WHERE, то точного совпадения оценки числа выбираемых строк и фактического их числа уже не будет. жүктеу/скачать 3,05 Mb. Достарыңызбен бөлісу:
|