Changes between Version 11 and Version 12 of QueryOptimization

Timestamp:

05/26/26 22:32:13 (7 hours ago)

Author:

231088

Comment:

--

QueryOptimization

@@ -888 +888 @@
 
 По оптимизацијата PostgreSQL започна да користи индексно пребарување наместо {{{Sequential Scan}}} за дел од join операциите, што значително го намали времето на извршување и бројот на обработени редици.
+
+
+
+== 9. Анализа и оптимизација на vw_pending_payments ==
+
+Погледот {{{vw_pending_payments}}} се користи за прикажување на pending и unpaid payments поврзани со bookings, артистите и настаните. Овој поглед се користи за financial tracking, artist dashboard и admin payment management.
+
+Прашалникот кој беше тестиран е следниот:
+
+{{{
+SELECT *
+FROM vw_pending_payments
+WHERE payment_status = 'PENDING';
+}}}
+
+=== Време на извршување без индекси ===
+
+'''9.1 - 12555.538 ms'''
+
+{{{
+Gather  (cost=579119.54..1056337.52 rows=4001410 width=258) (actual time=9089.762..12399.923 rows=4001410 loops=1)
+  ->  Hash Left Join
+        ->  Hash Join
+              ->  Parallel Hash Join
+                    ->  Parallel Seq Scan on payment p
+                          Filter: ((payment_status)::text = 'PENDING'::text)
+                    ->  Parallel Seq Scan on booking bk
+                    ->  Parallel Seq Scan on offer o
+                    ->  Parallel Seq Scan on bookingrequest br
+Planning Time: 2.158 ms
+Execution Time: 12555.538 ms
+}}}
+
+При почетната анализа со {{{EXPLAIN ANALYZE}}} беше забележано дека PostgreSQL користи {{{Sequential Scan}}} и {{{Parallel Sequential Scan}}} врз табелите {{{Payment}}}, {{{BookingRequest}}}, {{{Offer}}} и {{{Booking}}}. Ова предизвикуваше долго време на извршување бидејќи системот обработуваше милиони редици за да ги пронајде потребните payments и requests.
+
+За оптимизација беа додадени следните индекси:
+
+{{{
+CREATE INDEX idx_payment_status
+ON Payment(payment_status);
+
+CREATE INDEX idx_payment_booking
+ON Payment(booking_id);
+
+CREATE INDEX idx_booking_offer
+ON Booking(offer_id);
+
+CREATE INDEX idx_offer_bookable
+ON Offer(bookable_id);
+
+CREATE INDEX idx_offer_request
+ON Offer(request_id);
+
+CREATE INDEX idx_bookingrequest_eventdate
+ON BookingRequest(event_date);
+
+CREATE INDEX idx_bookingrequest_location
+ON BookingRequest(location_id);
+
+CREATE INDEX idx_location_city
+ON Location(city);
+
+CREATE INDEX idx_bookable_id
+ON Bookable(bookable_id);
+}}}
+
+=== Време на извршување со индекси ===
+
+'''9.1 - 10043.475 ms'''
+
+{{{
+Gather  (cost=579119.54..1056337.52 rows=4001410 width=258) (actual time=7499.460..9892.291 rows=4001410 loops=1)
+  ->  Hash Left Join
+        ->  Hash Join
+              ->  Parallel Hash Join
+                    ->  Parallel Seq Scan on payment p
+                          Filter: ((payment_status)::text = 'PENDING'::text)
+                    ->  Parallel Seq Scan on booking bk
+                    ->  Parallel Seq Scan on offer o
+                    ->  Parallel Seq Scan on bookingrequest br
+Planning Time: 3.268 ms
+Execution Time: 10043.475 ms
+}}}
+
+По оптимизацијата беше забележано подобрување кај query-от што пребарува според {{{payment_status = 'PENDING'}}}:
+
+ * од ~12.5 s
+ * на ~10.0 s
+
+И покрај тоа што PostgreSQL продолжи да користи делумни {{{Sequential Scan}}} операции поради големиот број редици, индексите помогнаа кај join операциите и дел од filtering процесите, што овозможи побрзо извршување на query-ите и подобар execution plan.
+
+Во вакви ситуации planner-от проценува дека sequential processing е поефикасен за обработка на огромен број редици, па индексите имаат ограничено влијание врз aggregation и join операциите.