Changes between Version 28 and Version 29 of OtherTopics

Timestamp:

06/24/26 02:26:11 (29 hours ago)

Author:

221181

Comment:

--

OtherTopics

@@ -142 +142 @@
 === Сценарио 1: Тековен залиха по складиште ===
 
-Цел: Прикажува вкупниот број производи и вредност на залихата по складишта.
+Цел: Прикажува вкупниот број производи и вредност на залихата по складишта.Прашањето врши агрегација (SUM) на целата табела.
 
 {{{
@@ -157 +157 @@
 }}}
 
-==== 1.1. Без индекс ====
-
-Кога се поврзува табелата **warehouse_stock** со табелата **product** преку колоната **product_id** (JOIN), ако нема индекс, базата на податоци ќе ги скенира сите редови.
+==== 1. Предложени индекси ====
+
+За да се забрза пребарувањето и поврзувањето, предложен е индекс на надворешниот клуч во табелата warehouse_stock:
+{{{
+CREATE INDEX idx_wh_stock_product_id ON stock_management.warehouse_stock(product_id);
+}}}
+
+==== 2. Анализа пред креирање на индексот (Без индекс) ====
 
 {{{
@@ -201 +206 @@
 '''Времетраење: 103.080 ms'''
 
-'''Анализа:''' Многу бавно.
-
-==== 1.2. Со индекс ====
-
-За пребарувањето по product_id во табелата warehouse_stock да биде побрзо
-
-'''Применет индекс:'''
-{{{
-CREATE INDEX idx_wh_stock_product_id ON stock_management.warehouse_stock(product_id);
-}}}
+
+==== 3. Анализа по креирање на индексот (Со индекс) ====
 
 {{{
@@ -244 +241 @@
 '''Времетраење: 29.767 ms '''
 
-'''Анализа:''' Многу по брзо.
+==== 4. Дали индексот навистина се користи во планот за извршување? ====
+Не. Доколку го анализираме планот за извршување (EXPLAIN PLAN) откако е креиран индексот, јасно се гледа дека PostgreSQL сè уште користи Seq Scan на warehouse_stock. Причината за ова е што барањето нема WHERE клаузула за филтрирање на специфични редови, тоа врши агрегација на сите податоци. За читање на 100% од редовите во една табела, Query Optimizer-от заклучува дека секвенцијалното скенирање е поефикасно од користењето на индекс.
+
+==== 5. Заклучок за перформансите ====
+Иако времето на извршување се намали од ~103ms на ~29ms, ова не се должи на индексот. Ова е класичен пример за кеширање податоците биле вчитани во меморијата при првото извршување (shared hits), што го направило второто извршување побрзо. Индексот idx_wh_stock_product_id би бил корисен само доколку додадеме WHERE филтер за конкретен производ (на пр. WHERE ws.product_id = 5).
 
 === Сценарио 2: Годишен извештај за продажба (последни 12 месеци) ===