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

96

Короткие запросы и индексы
Теперь план выполнения (показанный на рис. 5.26) выглядит совершенно 
иначе.
Рис. 5.26 

План выполнения с сортировкой
Запрос с последовательным сканированием выполнялся в течение 140 мил-
лисекунд; запрос с принудительным индексным доступом – в течение 
620 миллисекунд. Сравнение времен выполнения показывает, что последо-
вательное сканирование в данном случае действительно более эффективно.
н
е
 
мешайте
 P
ostgre
sQL 
делать
 
свое
 
дело
В этом разделе мы используем несколько модификаций запросов из преды-
дущих разделов, чтобы проиллюстрировать, как PostgreSQL изменяет планы 
выполнения на основе статистики данных.
Мы надеемся, что к настоящему времени вы получили убедительные до-
казательства того, что в большинстве случаев оптимизатор выполняет свою 
работу правильно, и обычно наша цель – не ограничивать гибкость и дать 
возможность сделать правильный выбор.
Вернемся к запросу по большой таблице из предыдущего раздела:
SELECT *
FROM boarding_pass_large
WHERE update_ts BETWEEN '2020-08-10' AND '2020-08-18'
LIMIT 100
План выполнения этого запроса показан на рис. 5.25. Оптимизатор Post-
greSQL выбрал последовательное сканирование, потому что интервал в семь 
дней слишком велик, чтобы получить какие-либо преимущества от индекс-
ного доступа. Теперь давайте сократим временной интервал:
SELECT *
FROM boarding_pass_large
WHERE update_ts BETWEEN '2020-08-15' AND '2020-08-18'
LIMIT 100
План выполнения этого запроса на рис. 5.27 показывает, что используется 
доступ на основе индекса.

---

Не мешайте PostgreSQL делать свое дело 
