Changes between Version 9 and Version 10 of QueryOptimization

Timestamp:

05/26/26 22:30:03 (7 hours ago)

Author:

231088

Comment:

--

QueryOptimization

@@ -765 +765 @@
 
 По оптимизацијата PostgreSQL престана да користи {{{Sequential Scan}}} за дел од пребарувањата и започна да користи индексно пребарување, што значително го намали времето на извршување и бројот на обработени редици.
+
+
+
+== 8. Анализа и оптимизација на vw_artist_incoming_requests ==
+
+Погледот {{{vw_artist_incoming_requests}}} се користи за прикажување на incoming requests за артистите и бендовите, вклучувајќи тип на настан, датум, град и понудена цена. Овој поглед се користи во artist dashboard делот од апликацијата.
+
+Прашалниците кои беа тестирани се следните:
+
+{{{
+-- 8.1
+SELECT *
+FROM vw_artist_incoming_requests
+WHERE city = 'Skopje';
+
+-- 8.2
+SELECT *
+FROM vw_artist_incoming_requests
+WHERE event_date >= '2026-07-01'
+AND event_date < '2026-08-01';
+}}}
+
+=== Време на извршување без индекси ===
+
+'''8.1 - 969.055 ms'''
+
+{{{
+Gather  (cost=204886.61..536618.31 rows=800000 width=254) (actual time=957.362..966.909 rows=0 loops=1)
+  ->  Hash Join
+        ->  Parallel Hash Join
+              ->  Parallel Seq Scan on bookingrequest br
+              ->  Seq Scan on location l
+                    Filter: ((city)::text = 'Skopje'::text)
+        ->  Parallel Seq Scan on offer o
+Planning Time: 0.612 ms
+Execution Time: 969.055 ms
+}}}
+
+'''8.2 - 8618.837 ms'''
+
+{{{
+Gather  (cost=209088.80..622293.48 rows=1677259 width=254) (actual time=7086.289..8549.231 rows=1701412 loops=1)
+  ->  Hash Left Join
+        ->  Parallel Hash Join
+              ->  Parallel Seq Scan on offer o
+              ->  Parallel Seq Scan on bookingrequest br
+                    Filter: ((event_date >= '2026-07-01'::date)
+                          AND (event_date < '2026-08-01'::date))
+Planning Time: 0.637 ms
+Execution Time: 8618.837 ms
+}}}
+
+При почетната анализа со {{{EXPLAIN ANALYZE}}} беше забележано дека PostgreSQL користи {{{Sequential Scan}}} и {{{Parallel Sequential Scan}}} врз табелите {{{Offer}}} и {{{BookingRequest}}}. Ова предизвикуваше дополнително време на извршување бидејќи системот обработуваше милиони редици за да ги пронајде потребните requests.
+
+За оптимизација беа додадени следните индекси:
+
+{{{
+CREATE INDEX idx_offer_bookable
+ON Offer(bookable_id);
+
+CREATE INDEX idx_offer_request
+ON Offer(request_id);
+
+CREATE INDEX idx_bookingrequest_location
+ON BookingRequest(location_id);
+
+CREATE INDEX idx_bookingrequest_eventdate
+ON BookingRequest(event_date);
+
+CREATE INDEX idx_location_city
+ON Location(city);
+
+CREATE INDEX idx_bookable_id
+ON Bookable(bookable_id);
+}}}
+
+=== Време на извршување со индекси ===
+
+'''8.1 - 617.537 ms'''
+
+{{{
+Gather  (cost=1030.26..345626.04 rows=800000 width=254) (actual time=606.861..615.460 rows=0 loops=1)
+  ->  Hash Join
+        ->  Nested Loop
+              ->  Hash Join
+                    ->  Parallel Seq Scan on bookingrequest br
+                    ->  Seq Scan on location l
+              ->  Index Scan using idx_offer_request on offer o
+Planning Time: 0.850 ms
+Execution Time: 617.537 ms
+}}}
+
+'''8.2 - 3438.192 ms'''
+
+{{{
+Gather  (cost=209088.80..622293.48 rows=1677259 width=254) (actual time=2096.594..3369.469 rows=1701412 loops=1)
+  ->  Hash Left Join
+        ->  Parallel Hash Join
+              ->  Parallel Seq Scan on offer o
+              ->  Parallel Seq Scan on bookingrequest br
+                    Filter: ((event_date >= '2026-07-01'::date)
+                          AND (event_date < '2026-08-01'::date))
+Planning Time: 0.865 ms
+Execution Time: 3438.192 ms
+}}}
+
+По оптимизацијата PostgreSQL започна да користи:
+
+ * {{{Index Scan}}}
+ * {{{Nested Loop}}}
+ * {{{Bitmap Heap Scan}}}
+
+Најголемо подобрување беше забележано кај query-от што пребарува според временски период:
+
+ * од ~8.6 s
+ * на ~3.4 s
+
+Кај query-от што пребарува според град {{{city = 'Skopje'}}} времето на извршување се подобри:
+
+ * од ~969 ms
+ * на ~617 ms
+
+По оптимизацијата PostgreSQL започна да користи индексно пребарување наместо {{{Sequential Scan}}} за дел од join операциите, што значително го намали времето на извршување и бројот на обработени редици.