по индексу . EXPLAIN SELECT book_ref

10.2. Методы просмотра таблиц
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), если никакие значения атрибутов не выбираются, а подсчиты-
вается лишь число этих строк? Казалось бы, достаточно использования только ин-
декса. Но это нужно для того, чтобы проверить видимость версий строк: ведь разные
транзакции могут видеть разные версии строк, поэтому при подсчете их числа нуж-
но учитывать, какой транзакции они видны. Обратите еще внимание на тот факт, что
собственно стадия агрегирования «ст´oит» не очень дорого. Ее можно приблизительно
оценить как 0,24 (отняв от оценки 14,48 в узле Aggregate оценку 14,24 в узле Bitmap
Heap Scan).
301

жүктеу/скачать 1.88 Mb.

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