| | 1 | = Фаза 3: Оптимизација на прашалници и погледи = |
| | 2 | |
| | 3 | Во оваа фаза е направена детална EXPLAIN ANALYZE анализа пред и по оптимизацијата, како и додавање на B-Tree индекси и рефакторирање на прашалниците. Целокупниот процес со плановите за извршување е документиран. |
| | 4 | |
| | 5 | Целосната документација со EXPLAIN ANALYZE резултатите (PDF) може да се преземе овде: |
| | 6 | * [attachment:Optimizacija_upita_i_pogleda.pdf Документација за оптимизација (симни тука)] |
| | 7 | |
| | 8 | == Анализа и оптимизација: new_event_ticket_sales_status == |
| | 9 | * '''Пред оптимизација:''' Извршувањето траеше '''~38.7 секунди''' (38712 ms) поради Sequential Scan на милиони записи и прелевање на сортирањето на диск (Disk Spill). |
| | 10 | * '''Оптимизација:''' Додадени се B-Tree индекси на надворешните клучеви (`idx_ticket_event_valid`) и применета е техниката Pre-aggregated Join (со користење на CTE за рано групирање пред спојување со големи табели). |
| | 11 | * '''По оптимизација:''' Времето на извршување е намалено на '''5.4 ms''', што е забрзување од над 99%. |
| | 12 | |
| | 13 | == Анализа и оптимизација: new_user_ticket_history == |
| | 14 | * '''Пред оптимизација:''' Времето на извршување изнесуваше огромни '''~138.2 секунди''' поради "Hash Batches" проблем и I/O тесно грло при спојување на табели од 8.9 и 5 милиони редици во меморија. |
| | 15 | * '''Оптимизација:''' Креирани се индексите `idx_reservation_user` и `idx_ticket_reservation`. |
| | 16 | * '''По оптимизација:''' При филтрирање за конкретен корисник, базата успешно користи Nested Loop операција, спуштајќи го времето на извршување на '''7.5 ms'''. |
| | 17 | |
| | 18 | == Општа оптимизација == |
| | 19 | За останатите погледи, додадени се индекси на надворешните клучеви (`idx_venue_city`, `idx_parking_venue`, `idx_staff_event`, итн.), што овозможува инстант пребарувања за помалку од 10 милисекунди. |
