Changes between Version 68 and Version 69 of QueryOptimization

Timestamp:

05/17/26 13:58:12 (9 days ago)

Author:

231027

Comment:

--

QueryOptimization

@@ -1324 +1324 @@
 }}}
 
-==== Без индекс:
+==== 1. Примарен филтер:
+
+Примарен филтер за овој поглед е `event_time > CURRENT_TIMESTAMP` во комбинација со `venue_id`. Корисниците најчесто сакаат да видат што се случува во нивниот град или во конкретен објект во блиска иднина.
+
+==== 2. Случај на употреба:
+
+Овој поглед е „срцето“ на насловната страница. Секој пат кога корисникот ќе ја отвори апликацијата или ќе филтрира настани по локација, овој прашалник се извршува. Тука перформансите се клучни за корисничкото искуство - ако репертоарот се вчита побавно од 2 s, корисникот веројатно ќе ја напушти страницата.
+
+==== 3. Иницијално време:
+
+Иницијалното време за извршување е многу ниско (0.193 ms), но забележливо е дека базата веќе користи постоечки уникатен индекс (`uq_happening_time_venue`). Проблемот тука не е брзината на еден прашалник, туку времето на планирање кое при комплексни филтри може да биде поголемо од самото извршување.
+
+==== 4. Анализа на планот на извршување (без индекси):
+
+Базата користи '''Index Scan''' врз постоечко уникатно ограничување.
+
+Сепак, при '''INSERT''' операцијата се појавува време од 573.660 ms, што е релативно високо за едноставно додавање на термин. Ова укажува на тоа дека базата троши време на проверка на интегритетот и пресметка на екстремните вредности ('''MAX''').
 
  * '''SELECT'''
@@ -1398 +1414 @@
 Времето на извршување е релативно ниско, но базата троши 4.258 ms само на планирање на секој поединечен запис. Бидејќи редовите не се подредени по време, системот мора да врши постојани споредби за секој настан. Заради ова, потребен е индекс кој ќе овозможи моментално лоцирање на идните настани без пребарување на целата табела.
 
-==== Оптимизација:
+==== 5. Оптимизација и индексирање:
+
+За да се овозможи максимална ефикасност при различни комбинации на филтрирање (само по време, само по локација или двете заедно), се предлагаат:
+
+ * `idx_event_happening_time`: За брзо хронолошко подредување.
+
+ * `idx_event_happening_venue_id`: За брзо филтрирање по објект.
+
+ * `idx_event_happening_venue_time`: Композитен индекс кој е идеален за прашалници кои бараат „претстојни настани во конкретна сала“.
 
 {{{
@@ -1413 +1437 @@
 }}}
 
-==== Со индекс:
+==== 6. Резултат по оптимизација:
+
+Времето на извршување останува стабилно ниско (0.215 ms).
+
+Најголемото подобрување се гледа кај '''INSERT''' операцијата, каде времето се намали од 573 ms на 1.278 ms. Ова е клучно бидејќи администраторите често додаваат нови термини во пакети, па ова забрзување значително го олеснува нивниот процес.
 
  * '''SELECT'''