Changes between Version 16 and Version 17 of QueryOptimization

Timestamp:

05/26/26 23:32:38 (6 hours ago)

Author:

231088

Comment:

--

QueryOptimization

@@ -1045 +1045 @@
 
 == 9. Анализа и оптимизација на vw_pending_payments ==
-
 Погледот {{{vw_pending_payments}}} се користи за прикажување на pending и unpaid payments поврзани со bookings, артистите и настаните. Овој поглед се користи за financial tracking, artist dashboard и admin payment management.
 
 Прашалникот кој беше тестиран е следниот:
-
 {{{
 SELECT *
@@ -1057 +1055 @@
 
 === Време на извршување без индекси ===
-
 '''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)
@@ -1077 +1073 @@
 
 За оптимизација беа додадени следните индекси:
-
 {{{
 CREATE INDEX idx_payment_status
@@ -1108 +1103 @@
 
 === Време на извршување со индекси ===
-
 '''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)
@@ -1126 +1119 @@
 
 По оптимизацијата беше забележано подобрување кај query-от што пребарува според {{{payment_status = 'PENDING'}}}:
-
  * од ~12.5 s
  * на ~10.0 s
@@ -1132 +1124 @@
 И покрај тоа што PostgreSQL продолжи да користи делумни {{{Sequential Scan}}} операции поради големиот број редици, индексите помогнаа кај join операциите и дел од filtering процесите, што овозможи побрзо извршување на query-ите и подобар execution plan.
 
-Во вакви ситуации planner-от проценува дека sequential processing е поефикасен за обработка на огромен број редици, па индексите имаат ограничено влијание врз aggregation и join операциите.
+Во вакви ситуации planner-от проценува дека sequential processing е поефикасен за обработка на огромен број редици, па индексите имаат ограничено влијание врз aggregation и join операциите. Поради ова, беше одлучено да се примени дополнителна оптимизација преку Материјализиран Поглед.
+
+=== Оптимизација со Материјализиран Поглед ===
+Бидејќи индексите не можеа значително да го подобрат времето на извршување поради огромниот број редици кои се враќаат (4 милиони), беше креиран Материјализиран Поглед ({{{MATERIALIZED VIEW}}}) кој ги зачувува резултатите физички на диск и овозможува побрзо пребарување без да се поминува низ сите join операции секој пат.
+{{{
+CREATE MATERIALIZED VIEW mv_pending_payments AS
+SELECT
+    p.payment_id,
+    bk.booking_id,
+    b.bookable_id,
+    b.display_name,
+    p.amount,
+    p.payment_status,
+    br.event_date,
+    l.city
+FROM Payment p
+JOIN Booking bk        ON p.booking_id = bk.booking_id
+JOIN Offer o           ON bk.offer_id = o.offer_id
+JOIN Bookable b        ON o.bookable_id = b.bookable_id
+JOIN BookingRequest br ON o.request_id = br.request_id
+LEFT JOIN Location l   ON br.location_id = l.location_id;
+
+CREATE UNIQUE INDEX idx_mv_payments_payment_id
+ON mv_pending_payments(payment_id);
+
+CREATE INDEX idx_mv_payments_status
+ON mv_pending_payments(payment_status);
+
+CREATE INDEX idx_mv_payments_city
+ON mv_pending_payments(city);
+
+CREATE INDEX idx_mv_payments_event_date
+ON mv_pending_payments(event_date);
+}}}
+
+=== Време на извршување со Материјализиран Поглед ===
+'''9.1 - 866.538 ms'''
+{{{
+Seq Scan on mv_pending_payments  (cost=0.00..89763.15 rows=4001532 width=49) (actual time=0.059..731.011 rows=4001410 loops=1)
+  Filter: ((payment_status)::text = 'PENDING'::text)
+Planning Time: 0.468 ms
+Execution Time: 866.538 ms
+}}}
+
+По креирањето на Материјализираниот Поглед беше забележано подобрување:
+ * од ~10.0 s (со индекси)
+ * на ~866 ms (со Материјализиран Поглед)
+
+Подобрувањето е присутно, меѓутоа PostgreSQL сè уште користи {{{Seq Scan}}} врз Материјализираниот Поглед бидејќи query-от враќа речиси сите редици (4 милиони од вкупно 4 милиони). Во ваква ситуација index scan е поскап од sequential scan бидејќи нема селективност — скоро секоја редица го задоволува филтерот {{{payment_status = 'PENDING'}}}.
+
+Главното подобрување доаѓа од тоа што сложените {{{JOIN}}} операции меѓу {{{Payment}}}, {{{Booking}}}, {{{Offer}}}, {{{Bookable}}} и {{{BookingRequest}}} се пресметани однапред и зачувани, па PostgreSQL скенира само еден објект наместо пет табели.
+
+За да останат податоците ажурирани, Материјализираниот Поглед се освежува по секоја промена на статусот на плаќање:
+{{{
+REFRESH MATERIALIZED VIEW CONCURRENTLY mv_pending_payments;
+}}}