Changes between Version 20 and Version 21 of QueryOptimization

Timestamp:

05/27/26 00:08:57 (19 hours ago)

Author:

233248

Comment:

--

QueryOptimization

@@ -188 +188 @@
 
 
+== View 8: Аналитика на производи по клиент == 
+
+'''Примарен филтер''' за погледот vw_klient_engagement ќе биде според klient_id, односно според клиентот за кој се пресметува бројот на активни банкарски производи. Овој поглед може да се користи и за анализа на клиенти според број на сметки или број на договори.
+
+
+Овој поглед ќе '''се користи за''' аналитика на клиентска активност во банкарскиот систем. Преку него се прикажува клиентот, неговото име и презиме, бројот на сметки и бројот на договори што ги има. Овој поглед е корисен за банката кога сака да види колку еден клиент е активен и колку производи користи.
+
+
+
+'''Иницијалното време''' за извршување на погледот без дополнителен индекс изнесува 68 ms. Вкупно време од 404 ms, но од тоа 68 ms е реалното execution време, додека 336 ms се однесуваат на fetching, односно преземање и прикажување на резултатите. Затоа како релевантно време за базата се зема execution времето од 68 ms. Ова време е прифатливо за апликацијата, особено затоа што погледот врши агрегирање и броење на поврзани записи.
+
+[[Image(view8.png, width=800)]]
+
+Од графичкиот план на извршување може да се забележи дека PostgreSQL користи Aggregate операција, бидејќи погледот пресметува број на сметки и број на договори. Дополнително, во планот се гледа Index Scan на табелата klient, а за поврзаните табели се користат операции за спојување со smetka и dogovor. Иако во планот може да се забележат Full Scan операции на smetka и dogov or, времето на извршување е доволно мало. Бидејќи погледот враќа само еден клиент и пресметува мал број агрегирани вредности, нема потреба од задолжително индексирање во моменталната состојба. 
+
+
+
+[[Image(view8.1.png, width=800)]]
+
+[[Image(view8.2.png, width=800)]]
+
+
+Нема потреба да се преуредува прашалникот.
+
+
+Времето на извршување на операциите останува исто.
+
+
+
+== View 9: Преглед на налози / плаќања по клиент ==
+
+'''Примарен филтер''' за погледот vw_nalozi_klienti ќе биде според klient_id, односно според клиентот кој е налогодавач на плаќањето. Дополнително, погледот може да се користи и за пребарување според smetka_nalogodavac_id, бидејќи налозите се поврзани и со конкретна сметка од која се врши плаќањето.
+
+
+Овој поглед ќе '''се користи за''' преглед на налози, односно плаќања направени од клиент. Преку него се прикажуваат износот на плаќањето, целта на плаќањето, датумот на валута, клиентот налогодавач и сметката од која е направено плаќањето. Овој поглед е важен затоа што налозите и плаќањата се една од најчесто користените функционалности во банкарскиот систем.
+
+
+'''Иницијалното време''' за извршување на погледот без дополнителен индекс изнесува 4 s 127 ms. Вкупно време од 4 s 468 ms, од кое 4 s 127 ms е реалното execution време, додека 341 ms се однесуваат на fetching. Бидејќи execution времето е над 4 секунди, ова не е прифатливо време за апликацијата и има потреба од оптимизација. 
+
+[[Image(view9.png, width=800)]]
+
+
+Од графичкиот план на извршување може да се забележи дека најбавната операција е Full Scan / Seq Scan на табелата nalog. Табелата nalog има голем број записи, а пребарувањето се прави според nalogodavac_id = 50000. Бидејќи нема соодветен индекс, PostgreSQL мора да ја пребара целата табела за да ги пронајде налозите на конкретниот клиент. Ова покажува дека колоната nalogodavac_id е главен кандидат за индексирање. Дополнително, бидејќи погледот се поврзува и преку smetka_nalogodavac_id, корисен е и индекс на таа колона. 
+
+
+[[Image(view9.1.png, width=800)]]
+[[Image(view9.2.png, width=800)]]
+
+
+Времето изминато во извршување на query-то со индекси изнесува 406ms, и тоа е прифатливо време. 
+
+
+[[Image(view9.3.png, width=800)]]
+[[Image(view9.4.png, width=800)]]
+
+Времето изминато во извршување на операциите insert и update по индексирање изнесува: 
+
+[[Image(view9.5.png, width=800)]]
+