-> Seq Scan on tickets t
(cost=0.00..9733.33 rows=366733 width=7)
(actual time=0.047..170.792 rows=366733 loops=1)
-> Hash (cost=5615.82..5615.82 rows=1314 width=7)
(actual time=498.624..498.624 rows=165534
loops=1)
,
→
Buckets: 262144 (originally 2048)
Batches: 2 (originally 1)
Memory Usage: 3457kB
-> Seq Scan on bookings b
(cost=0.00..5615.82 rows=1314 width=7)
(actual time=0.019..267.728 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
Planning time: 2.183 ms
Execution time: 4221.133 ms
(21 строка)
В данном плане используется соединение хешированием (Hash Join). При этом ин-
декс по таблице tickets игнорируется: она просматривается последовательно (Seq
Scan on tickets t). Время выполнения модифицированного запроса оказывается
несколько большим, чем в предыдущем случае, когда в запросе присутствовал корре-
лированный подзапрос. Таким образом, можно заключить, что для ускорения работы
оригинального запроса можно было либо создать индекс, либо модифицировать сам
запрос, даже не создавая индекса.
Другие методы оптимизации выполнения запросов представлены в разделе «Кон-
трольные вопросы и задания». Рекомендуем вам самостоятельно с ними ознакомить-
ся и поэкспериментировать.
Перед выполнением упражнений нужно восстановить измененные значения пара-
метров:
Достарыңызбен бөлісу: