==Индексирање

Замислете да имаме база на податоци со милиони податоци. Ако сакаме да дојдеме до одредена редица ќе треба да ги изминеме сите податоци во истата. Овој пристап е навистина неефикасен и спор. Токму затоа постои индексирањето, односно забрзување на пристап до саканите податоци, така што базата користи индексни структури за да ги лоцираат податоците по нивните клучеви.

Ќе видиме како се прават индексирање врз нашата база и ќе видиме какви видови индекси може да направиме.

-Во првиот случај имаме единечен индекс

{{{create index idx_player_transfers_player_id

on transfers(player_id) }}}

explain analyze 

select * 

from transfers 

where player_id = 101; 

Имаме Index Scan, што значи дека PostgreSQL користи индекс а не full table scan

Startup_cost=0.29 -> ова е времето за пронаоѓање на вредноста во В-tree индексот

Total_cost=29.30 -> цената да се вратат сите редови што го исполнуваат условот

Buffers: shared read=2 -> податоците не биле во РАМ и морало да се прочитаат од диск, но 2 блока е прилично ефикасно

Планирањето трае повеќе од пребарувањето

Ако немавме индекс Seq Scan ќе ги читаше сите трансфери еден по еден

-Во овој случај имаме композитен индекс

create index idx_player_transfers_player_date 

on transfers(player_id, transfer_date) 

select * 

from transfers  

where player_id = 16136 

	and transfer_date >= '2026-07-01' 

Buffers: shared hit=3 read=1 -> 3 блока веќе биле во РАМ, 1 блок од диск

Во композитен индекс многу е важно да се запази редоследот. На пример, во овој случај, ако transfer_date беше на прво место, перформансите ќе беа многу полоши поради тоа што е опсег.

Видовме дека индексирањето е неопходно за една база на податоци. Главни предности на индексирањето се забрзување на пребарувањата, подобрен пристап и сортирање, интегритет на податоците...

Сега да ги видиме е лошите страни на индексирањето. Да кажеме дека сакаме да внесеме нов запис во базата преку INSERT.

insert into transfers(player_id, transfer_date, transfer_season, from_club_id, to_club_id, from_club_name , to_club_name, transfer_fee, market_value_in_eur, player_name) 

values (16136, '2024-07-01', '25/26', 336, 631, 'Sporting', 'Chelsea', 50000000, 4000000, 'Dante') 

Во овој случај внесувањето на запис, иако навидум едноставно, има еден проблем - секој индекс на табелата мора да се ажурира. Најпрво треба за секој индекс да ја најдеме точната позиција во B-tree, потоа да се внесе нов индекс, па дури потоа да се запише во WAL. Истото се случува и при ажурирање со UPDATE, па дури и полошо. PostgreSQL мора да избрише стар индекс, па да го внесе новиот, па повторно да изврши WAL.

update transfers  

set transfer_date = '2026-02-01' 

where player_id = 16136 

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