Учебно-практическое пособие москва 2017 ббк
жүктеу/скачать 3,05 Mb. Pdf көрінісі
|
Язык SQL. Базовый курс
- Бұл бет үшін навигация:
- EXPLAIN SELECT num_tickets, count( * ) AS num_bookings FROM ( SELECT b.book_ref, ( SELECT count( * ) FROM tickets t
- GROUP by num_tickets ORDER BY num_tickets DESC;
| ANALYZE aircrafts;
ANALYZE В качестве примера ситуации, в которой оптимизация запроса представляется обос- нованной, рассмотрим следующую задачу. Предположим, что необходимо опреде- лить степень загруженности кассиров нашей авиакомпании в сентябре 2016 г. Для этого, в частности, требуется выявить распределение числа операций бронирования по числу билетов, оформленных в рамках этих операций. Другими словами, это озна- чает, что нужно подсчитать число операций бронирования, в которых был оформлен только один билет, число операций, в которых было оформлено два билета и т. д. Эту задачу можно переформулировать так: для каждой строки, отобранной из таб- лицы «Бронирования» (bookings), нужно подсчитать соответствующие строки в таб- лице «Билеты» (tickets). Речь идет о строках, в которых значение поля book_ref такое же, что и в текущей строке таблицы bookings. Буквальное следование такой форму- лировке задачи приводит к получению запроса с коррелированным подзапросом в предложении SELECT. Но это еще не окончательное решение. Теперь нужно сгруппи- ровать полученный набор строк по значениям числа оформленных билетов. Получаем такой запрос: EXPLAIN SELECT num_tickets, count( * ) AS num_bookings FROM ( SELECT b.book_ref, ( SELECT count( * ) FROM tickets t WHERE t.book_ref = b.book_ref ) FROM bookings b WHERE date_trunc( 'mon', book_date ) = '2016-09-01' ) AS count_tickets( book_ref, num_tickets ) GROUP by num_tickets ORDER BY num_tickets DESC; QUERY PLAN ------------------------------------------------------------------ GroupAggregate (cost=14000017.12..27994373.35 rows=1314 width=16) Group Key: ((SubPlan 1)) -> Sort (cost=14000017.12..14000020.40 rows=1314 width=8) Sort Key: ((SubPlan 1)) DESC -> Seq Scan on bookings b (cost=0.00..13999949.05 rows=1314 width=8) Filter: (date_trunc('mon'::text, book_date) = '2016-09-01 00:00:00+08'::timestamp with time zone) SubPlan 1 -> Aggregate (cost=10650.17..10650.18 rows=1 width=8) -> Seq Scan on tickets t (cost=0.00..10650.16 rows=2 width=0) 243 Filter: (book_ref = b.book_ref) (10 строк) В этом плане получены очень большие оценки общей стоимости выполнения запро- са: cost=14000017.12..27994373.35. Универсальной зависимости между оценкой сто- имости и реальным временем выполнения запроса не существует. Не всегда можно даже приблизительно предположить, в какие затраты времени выльется та или иная оценка стоимости. Но, тем не менее, в тексте главы при рассмотрении других запро- сов оценок такого порядка еще не встречалось. Планировщик предполагает, что из таблицы tickets в подзапросе будет извлекаться всего по две строки, и эту операцию нужно будет проделать 1314 раз: столько строк предположительно будет выбрано из таблицы bookings. Как видно из плана, для просмотра строк в таблице tickets исполь- зуется ее последовательное сканирование. В результате оценка стоимости этого узла плана получается высокой — cost=0.00..10650.16. Если у вас не очень мощный компьютер, то время получения результата может выйти за разумные пределы, и вам придется прервать процесс с помощью клавишей Ctrl- C. Что можно сделать для ускорения выполнения запроса? Давайте создадим индекс для таблицы tickets по столбцу book_ref, по которому происходит поиск в ней. жүктеу/скачать 3,05 Mb. Достарыңызбен бөлісу:
|