Changes between Version 5 and Version 6 of QueryOptimization

Timestamp:

05/26/26 22:18:11 (16 hours ago)

Author:

231088

Comment:

--

QueryOptimization

@@ -307 +307 @@
 
 Во вакви ситуации planner-от проценува дека sequential processing е поефикасен од index traversal, па индексите имаат ограничено влијание врз вкупното време на извршување.
+
+
+== 4. Анализа и оптимизација на vw_trending_bookables ==
+
+Погледот {{{vw_trending_bookables}}} се користи за прикажување на најпопуларните артисти и бендови според бројот на bookings и просечниот рејтинг. Овој поглед се користи за homepage recommendations и analytics.
+
+Прашалникот кој беше тестиран е следниот:
+
+{{{
+SELECT *
+FROM vw_trending_bookables
+ORDER BY total_bookings DESC
+LIMIT 10;
+}}}
+
+=== Време на извршување без индекси ===
+
+'''4.1 - 22675.664 ms'''
+
+{{{
+Limit  (cost=1149893.25..1149893.28 rows=10 width=61) (actual time=22673.555..22673.564 rows=10 loops=1)
+  ->  Sort
+        Sort Key: (count(bk.booking_id)) DESC
+        ->  HashAggregate
+              Group Key: b.bookable_id
+              ->  Hash Right Join
+                    ->  Hash Left Join
+                          ->  Seq Scan on offer o
+                          ->  Seq Scan on booking bk
+                          ->  Seq Scan on review r
+Planning Time: 1.190 ms
+Execution Time: 22675.664 ms
+}}}
+
+При почетната анализа со {{{EXPLAIN ANALYZE}}} беше забележано дека PostgreSQL користи {{{Sequential Scan}}} врз табелите {{{Offer}}}, {{{Booking}}} и {{{Review}}}, како и {{{HashAggregate}}} и {{{Sort}}} операции за пресметување на бројот на bookings и просечниот рејтинг.
+
+Поради огромниот број редици и aggregation операции, query-от имаше многу долго време на извршување.
+
+За оптимизација беа додадени следните индекси:
+
+{{{
+CREATE INDEX idx_offer_bookable
+ON Offer(bookable_id);
+
+CREATE INDEX idx_booking_offer
+ON Booking(offer_id);
+
+CREATE INDEX idx_review_booking
+ON Review(booking_id);
+
+CREATE INDEX idx_review_rating
+ON Review(rating);
+
+CREATE INDEX idx_bookable_id
+ON Bookable(bookable_id);
+}}}
+
+=== Време на извршување со индекси ===
+
+'''4.1 - 22582.888 ms'''
+
+{{{
+Limit  (cost=1149893.25..1149893.28 rows=10 width=61) (actual time=22580.768..22580.777 rows=10 loops=1)
+  ->  Sort
+        Sort Key: (count(bk.booking_id)) DESC
+        ->  HashAggregate
+              Group Key: b.bookable_id
+              ->  Hash Right Join
+                    ->  Hash Left Join
+                          ->  Seq Scan on offer o
+                          ->  Seq Scan on booking bk
+                          ->  Seq Scan on review r
+Planning Time: 1.633 ms
+Execution Time: 22582.888 ms
+}}}
+
+По оптимизацијата беше забележано мало подобрување кај query-от што ги прикажува најпопуларните артисти:
+
+ * од ~22.6 s
+ * на ~22.5 s
+
+И покрај додадените индекси, PostgreSQL продолжи да користи {{{Sequential Scan}}} бидејќи query-от обработува огромен број редици и користи сложени aggregation операции како {{{COUNT}}}, {{{AVG}}}, {{{GROUP BY}}} и {{{ORDER BY}}}.
+
+Во вакви ситуации planner-от проценува дека sequential processing е поефикасен од index traversal, па индексите имаат ограничено влијание врз вкупното време на извршување.