Changes between Version 12 and Version 13 of otherdevelopment


Ignore:
Timestamp:
07/02/26 16:07:13 (4 days ago)
Author:
233062
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • otherdevelopment

    v12 v13  
    1010- Пред додавање на индексот го извршуваме **целиот прашалник на извештајот** 10 пати користејќи `EXPLAIN ANALYZE`. Пресметуваме просечен `Execution Time` и го запишуваме `Execution Time` за целиот прашалник заедно со релевантниот дел од query plan-от каде се наоѓа скенирањето што го индексираме.
    1111- По додавање на индексот го извршуваме истиот прашалник 10 пати и ги споредуваме резултатите и плановите.
    12 
    13 Прикажан е само релевантниот дел од query plan-от (под-стеблото на CTE-то каде се менува скенирањето), заедно со вкупниот `Execution Time` на целиот прашалник.
    14 
    15 **Забелешка за филтерот по година:** годишниот филтер е напишан како **sargable опсег** (`date >= '2026-01-01' AND date < '2027-01-01'`) наместо `EXTRACT(YEAR FROM date) = 2026`. Ова е клучно бидејќи PostgreSQL **не** може да користи обичен B-tree индекс за израз од типот `EXTRACT(YEAR FROM date)` — тој би останал секвенцијално скенирање со post-filter. Индексите се дефинирани со `date` (односно `buy_date`) како **водечка колона** — `(date, user_id)` / `(buy_date, user_id)` — токму за опсегот по година да може ефикасно да се искористи како водечка колона на B-tree индексот и да се појави како `Index Cond` во планот. (Ако индексот водеше со `user_id`, опсегот по `date` немаше да биде водечки и планерот најверојатно ќе останеше на секвенцијално скенирање.) Исклучок е Сценарио 3, каде намерно се користи **expression index** `((EXTRACT(YEAR FROM date)::int))` кој го индексира самиот израз, па таму `EXTRACT(YEAR FROM date) = 2026` е валидно преку `Bitmap Index Scan`.
    1612
    1713=== Сценарио 1