Changes between Version 6 and Version 7 of QueryOptimization

Timestamp:

05/26/26 22:20:19 (16 hours ago)

Author:

231088

Comment:

--

QueryOptimization

@@ -391 +391 @@
 
 Во вакви ситуации planner-от проценува дека sequential processing е поефикасен од index traversal, па индексите имаат ограничено влијание врз вкупното време на извршување.
+
+
+
+== 5. Анализа и оптимизација на vw_artist_dashboard ==
+
+Погледот {{{vw_artist_dashboard}}} се користи за прикажување на статистики за артистите и бендовите, вклучувајќи број на bookings, вкупна заработка и просечен рејтинг. Овој поглед се користи во artist dashboard делот од апликацијата.
+
+Прашалникот кој беше тестиран е следниот:
+
+{{{
+SELECT *
+FROM vw_artist_dashboard
+WHERE average_rating >= 4.5;
+}}}
+
+=== Време на извршување без индекси ===
+
+'''5.1 - 32835.819 ms'''
+
+{{{
+HashAggregate  (cost=1485307.72..1485320.22 rows=200 width=87) (actual time=32833.146..32833.154 rows=0 loops=1)
+  Group Key: b.bookable_id
+  Filter: (round(avg(r.rating), 2) >= 4.5)
+  ->  Hash Right Join
+        ->  Hash Left Join
+              ->  Seq Scan on offer o
+              ->  Seq Scan on booking bk
+              ->  Seq Scan on payment p
+              ->  Seq Scan on review r
+Planning Time: 0.945 ms
+Execution Time: 32835.819 ms
+}}}
+
+При почетната анализа со {{{EXPLAIN ANALYZE}}} беше забележано дека PostgreSQL користи {{{Sequential Scan}}} врз табелите {{{Offer}}}, {{{Booking}}}, {{{Payment}}} и {{{Review}}}, како и {{{HashAggregate}}} операции за пресметување на заработката и просечниот рејтинг.
+
+Поради големиот број редици и aggregation операции, query-от имаше многу долго време на извршување.
+
+За оптимизација беа додадени следните индекси:
+
+{{{
+CREATE INDEX idx_offer_bookable
+ON Offer(bookable_id);
+
+CREATE INDEX idx_booking_offer
+ON Booking(offer_id);
+
+CREATE INDEX idx_payment_booking
+ON Payment(booking_id);
+
+CREATE INDEX idx_payment_status
+ON Payment(payment_status);
+
+CREATE INDEX idx_review_booking
+ON Review(booking_id);
+
+CREATE INDEX idx_review_rating
+ON Review(rating);
+}}}
+
+=== Време на извршување со индекси ===
+
+'''5.1 - 30002.268 ms'''
+
+{{{
+HashAggregate  (cost=1485307.72..1485320.22 rows=200 width=87) (actual time=29999.572..29999.580 rows=0 loops=1)
+  Group Key: b.bookable_id
+  Filter: (round(avg(r.rating), 2) >= 4.5)
+  ->  Hash Right Join
+        ->  Hash Left Join
+              ->  Seq Scan on offer o
+              ->  Seq Scan on booking bk
+              ->  Seq Scan on payment p
+              ->  Seq Scan on review r
+Planning Time: 1.395 ms
+Execution Time: 30002.268 ms
+}}}
+
+По оптимизацијата беше забележано подобрување кај query-от што филтрира според просечен рејтинг:
+
+ * од ~32.8 s
+ * на ~30.0 s
+
+И покрај тоа што PostgreSQL продолжи да користи {{{Sequential Scan}}}, индексите помогнаа при join операциите и hash processing, што резултираше со побрзо извршување на query-от.
+
+Бидејќи погледот користи сложени aggregation операции како {{{SUM}}}, {{{AVG}}}, {{{COUNT}}} и {{{GROUP BY}}}, planner-от проценува дека sequential processing е поефикасен од index traversal при обработка на голем број редици.