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

Листинг 7.13 

Запрос к секционированной таблице
SELECT city,
date_trunc('month', scheduled_departure),
sum(passengers) passengers
FROM airport a
JOIN flight f ON airport_code = departure_airport
JOIN (
SELECT flight_id, count(*) passengers
FROM booking_leg l
JOIN boarding_pass_part b USING (booking_leg_id)
WHERE boarding_time > '07-15-20'
AND boarding_time < '07-31-20'
GROUP BY flight_id
) cnt USING (flight_id)
GROUP BY 1,2
ORDER BY 3 DESC
План выполнения на рис. 7.7 показывает, что вместо сканирования всей 
таблицы оптимизатор решает сканировать только одну секцию, поскольку 

---

154

Длинные запросы: дополнительные приемы
запрос содержит фильтр по времени посадки. Время выполнения запро-
са для несекционированной таблицы примерно одинаково независимо от 
фильтрации по времени посадки, но для секционированной таблицы время 
выполнения уменьшается в два с лишним раза, потому что все строки на-
ходятся в одной секции.
Рис. 7.7 

План выполнения с секционированной таблицей
У секций могут быть собственные индексы, которые, очевидно, меньше 
индекса всей секционированной таблицы. Этот вариант может быть полезен 
для коротких запросов, однако производительность возрастет существенно 
только в том случае, если почти все запросы извлекают данные из одной 
и той же секции. Затраты на поиск в B-дереве пропорциональны его глуби-
не. Индекс по секции, скорее всего, устранит только один уровень B-дерева, 
а выбор необходимой секции также требует некоторого количества ресурсов. 

---

Параллелизм 

155
Эти ресурсы, вероятно, сопоставимы со стоимостью чтения дополнительного 
уровня индекса. Конечно, запрос может обращаться к конкретной секции, 
а не ко всей секционированной таблице, скрывая затраты на выбор секции 
для приложения, отправляющего запрос.
Поэтому не следует переоценивать преимущества секционирования для 
коротких запросов.