Учебное пособие Санкт-Петербург «бхв-петербург»
CREATE INDEX tickets_book_ref_key
жүктеу/скачать 1.88 Mb. Pdf көрінісі
|
| CREATE INDEX tickets_book_ref_key
ON tickets ( book_ref ); CREATE INDEX Повторим запрос, добавив параметр ANALYZE в команду EXPLAIN. Новый план, в ко- тором отражены и фактические результаты, будет таким: QUERY PLAN ------------------------------------------------------------------------- GroupAggregate (cost=22072.70..38484.52 rows=1314 width=16) (actual time=3656.554..3787.562 rows=5 loops=1) Group Key: ((SubPlan 1)) -> Sort (cost=22072.70..22075.99 rows=1314 width=8) (actual time=3656.533..3726.969 rows=165534 loops=1) Sort Key: ((SubPlan 1)) DESC Sort Method: external merge Disk: 2912kB -> Seq Scan on bookings b (cost=0.00..22004.64 rows=1314 width=8) (actual time=0.219..3332.162 rows=165534 loops=1) Filter: (date_trunc('mon'::text, book_date) = '2016-09-01 00:00:00+08'::timestamp with time zone) Rows Removed by Filter: 97254 SubPlan 1 -> Aggregate (cost=12.46..12.47 rows=1 width=8) (actual time=0.016..0.016 rows=1 loops=165534) -> Index Only Scan using tickets_book_ref_key on tickets t (cost=0.42..12.46 rows=2 width=0) (actual time=0.013..0.014 rows=1 loops=165534) Index Cond: (book_ref = b.book_ref) Heap Fetches: 230699 Planning time: 0.290 ms Execution time: 3788.690 ms (15 строк) 314 10.5. Оптимизация запросов Теперь планировщик использует индекс для поиска в таблице tickets. Причем это поиск исключительно по индексу (Index Only Scan), поскольку нас интересует толь- ко число строк — count( * ), а не их содержание. Обратите внимание на различие предполагаемого и фактического числа извлекаемых строк. Тем не менее запрос стал выполняться значительно — на порядок — быстрее. Результат имеет такой вид: num_tickets | num_bookings -------------+-------------- 5 | 13 4 | 536 3 | 7966 2 | 47573 1 | 109446 (5 строк) Кроме создания индекса есть и другой способ: замена коррелированного подзапроса соединением таблиц. жүктеу/скачать 1.88 Mb. Достарыңызбен бөлісу:
|