= Оптимизација на прашалници


== Анализа и оптимизација на `Venue_Layout`

Овој поглед ја прикажува деталната физичка структура на секој објект (сала), поврзувајќи ги поединечните седишта со нивните сектори и самите локации. Патеката на релациите е поставена линеарно, овозможувајќи брза проверка на точната позиција на седиштето преку неговиот ред и број.

{{{

CREATE OR REPLACE VIEW "Venue_Layout" AS
SELECT v.venue_id,
       v.name AS venue_name,
       s.section_id,
       s.name AS section_name,
       st.seat_id,
       st.row_number,
       st.seat_number
FROM "Venue" v
JOIN "Section" s ON v.venue_id = s.venue_id
JOIN "Seat" st ON s.section_id = st.section_id;

}}}

==== 1. Примарен филтер:

Примарен филтер за овој поглед е `venue_id` (ID на објектот), бидејќи најчестото пребарување е насочено кон визуелизација или вчитување на комплетната мапа на седишта за еден конкретен објект кога се купува билет.

==== 2. Случај на употреба:

Погледот се користи при интерактивниот приказ на салата/стадионот во корисничкиот интерфејс. Кога купувачот ќе избере настан, апликацијата мора веднаш да го исцрта распоредот на седишта по секции и редови за тој објект. Перформансите тука директно влијаат врз брзината на вчитување на корисничката страница за избор на седиште.

==== 3. Иницијално време:

 * '''SELECT:''' 0.475 ms (Екстремно брзо поради постоечките уникатни констреинти `uq_section_venue_name` на табелата `Section` и `uq_seat_section_number` на табелата `Seat`).
 * '''INSERT:''' 19.912 ms (Релативно бавно, каде што најголемиот дел од времето паѓа на тригер проверката за '''foreign key''' констреинтот).
 * '''UPDATE:''' 0.137 ms (Инстантна брзина благодарение на примарниот клуч).

==== 4. Анализа на планот на извршување (без индекси):

При '''SELECT''' операцијата, PostgreSQL паметно ги користи веќе постоечките уникатни индекси генерирани од бизнис констреинтите, овозможувајќи брз '''Index Scan'''. Меѓутоа, при '''INSERT''' во табелата `Seat`, базата троши дури 19.752 ms само на тригерот за проверка на '''foreign key''' (`fk_seat_section`), бидејќи без ажурирана статистика, планерот мора рачно да ја проверува релацијата на диск.

 * '''SELECT'''

{{{

EXPLAIN ANALYZE
SELECT * FROM "Venue_Layout"
WHERE venue_id = 1;

}}}

||= QUERY PLAN =||
||Nested Loop  (cost\=1.01..8110.27 rows\=1886 width\=54) (actual time\=0.152..0.475 rows\=775.00 loops\=1)||
||  Buffers: shared hit\=21 read\=13 dirtied\=1||
||  ->  Nested Loop  (cost\=0.57..23.73 rows\=5 width\=38) (actual time\=0.129..0.131 rows\=5.00 loops\=1)||
||        Buffers: shared read\=6||
||        ->  Index Scan using ""Venue_pkey"" on ""Venue"" v  (cost\=0.29..8.30 rows\=1 width\=28) (actual time\=0.061..0.061 rows\=1.00 loops\=1)||
||              Index Cond: (venue_id \= 1)||
||              Index Searches: 1||
||              Buffers: shared read\=3||
||        ->  Index Scan using uq_section_venue_name on ""Section"" s  (cost\=0.29..15.38 rows\=5 width\=18) (actual time\=0.051..0.052 rows\=5.00 loops\=1)||
||              Index Cond: (venue_id \= 1)||
||              Index Searches: 1||
||              Buffers: shared read\=3||
||  ->  Index Scan using uq_seat_section_number on ""Seat"" st  (cost\=0.44..1608.23 rows\=908 width\=24) (actual time\=0.009..0.050 rows\=155.00 loops\=5)||
||        Index Cond: (section_id \= s.section_id)||
||        Index Searches: 5||
||        Buffers: shared hit\=21 read\=7 dirtied\=1||
||Planning:||
||  Buffers: shared hit\=4 read\=11||
||Planning Time: 0.631 ms||
||Execution Time: 0.577 ms||

 * '''INSERT'''

{{{

EXPLAIN ANALYZE
INSERT INTO "Seat" (seat_id, section_id, row_number, seat_number)
VALUES (99999999, 1, 1, 99);

}}}

||= QUERY PLAN =||
||Insert on ""Seat""  (cost\=0.00..0.01 rows\=0 width\=0) (actual time\=0.135..0.136 rows\=0.00 loops\=1)||
||  Buffers: shared hit\=5 read\=3 dirtied\=1||
||  ->  Result  (cost\=0.00..0.01 rows\=1 width\=24) (actual time\=0.001..0.001 rows\=1.00 loops\=1)||
||Planning Time: 0.058 ms||
||Trigger for constraint fk_seat_section: time\=19.752 calls\=1||
||Execution Time: 19.912 ms||

 * '''UPDATE'''

{{{

EXPLAIN ANALYZE
UPDATE "Seat"
SET seat_number = 100
WHERE seat_id = 99999999;

}}}

||= QUERY PLAN =||
||Update on ""Seat""  (cost\=0.44..8.46 rows\=0 width\=0) (actual time\=0.106..0.106 rows\=0.00 loops\=1)||
||  Buffers: shared hit\=12||
||  ->  Index Scan using ""Seat_pkey"" on ""Seat""  (cost\=0.44..8.46 rows\=1 width\=10) (actual time\=0.048..0.049 rows\=1.00 loops\=1)||
||        Index Cond: (seat_id \= 99999999)||
||        Index Searches: 1||
||        Buffers: shared hit\=4||
||Planning Time: 0.171 ms||
||Execution Time: 0.137 ms||

==== 5. Оптимизација и индексирање:

Бидејќи постоечките уникатни констреинти веќе идеално ги покриваат '''JOIN''' релациите, креирањето на дополнителни индекси е непотребно и би довело до залудно трошење на мемориски ресурси. Наместо тоа, за да го решиме тесното грло при '''INSERT''' операциите, се извршува наредбата ANALYZE за табелите во релација со цел да се обноват статистиките на внатрешниот планер.

{{{

ANALYZE;

}}}

==== 6. Резултат по оптимизација:

По извршување на '''ANALYZE''', базата стекна целосен увид во дистрибуцијата на податоците, со што времето на '''INSERT''' се намали на 0.628 ms, што претставува забрзување од околу 30 пати. Операциите за '''SELECT''' и '''UPDATE''' ги задржаа своите врвни перформанси во под-милисекунден опсег.