сканирования исключительно

QUERY PLAN
----------------------------------------------------------------
Index Only Scan using bookings_pkey on bookings (cost=0.42..9.42 rows=57
width=7)
,
→
Index Cond: (book_ref < '000FFF'::bpchar)
(2 строки)
В этом плане только один узел — Index Only Scan. Здесь также первая оценка стоимо-
сти не нулевая, т. к. отыскание в индексе наименьшего значения требует некоторого
времени.
Посмотрим, как отражаются в планах выполнения запросов различные
агрегатные
функции
. Начнем с простого подсчета строк.
EXPLAIN
SELECT count( * )
FROM seats
WHERE aircraft_code = 'SU9';
QUERY PLAN
----------------------------------------------------------------
Aggregate (cost=14.48..14.49 rows=1 width=8)
-> Bitmap Heap Scan on seats (cost=5.03..14.24 rows=97 width=0)
Recheck Cond: (aircraft_code = 'SU9'::bpchar)
-> Bitmap Index Scan on seats_pkey (cost=0.00..5.00 rows=97
width=0)
,
→
Index Cond: (aircraft_code = 'SU9'::bpchar)
(5 строк)
В верхнем узле плана выполняется агрегирование — Aggregate. А в нижних узлах под-
готавливаются строки с помощью сканирования на основе формирования битовой
карты.
Но возникает вопрос: зачем вообще выполняется обращение к страницам таблицы
(Bitmap Heap Scan), если никакие значения атрибутов не выбираются, а подсчитыва-
ется лишь число этих строк? Казалось бы, достаточно использования только индек-
са. Но это нужно для того, чтобы проверить видимость версий строк: ведь разные
транзакции могут видеть разные версии строк, поэтому при подсчете их числа нуж-
но учитывать, какой транзакции они видны. Обратите еще внимание на тот факт, что
собственно стадия агрегирования «стоит» не очень дорого. Ее можно приблизитель-
но оценить как 0,24 (отняв от оценки 14,48 в узле Aggregate оценку 14,24 в узле Bitmap
Heap Scan).
А в этом примере агрегирование связано уже с вычислениями на основе значений
конкретного столбца, а не просто с подсчетом строк.

жүктеу/скачать 3,05 Mb.

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