Promjene potrebne u API-ju Table\/Index AM za podr\u0161ku alternativnim implementacijama MVCC razmatraju se s obzirom na ekstenziju OrioleDB, razvijenu za rje\u0161avanje poznatih nedostataka ugra\u0111enog mehanizma pohrane PostgreSQL-a. Problem je u tome \u0161to su za potpunu integraciju OrioleDB-a s PostgreSQL-om potrebne promjene u kodu PostgreSQL-a, \u0161to ote\u017eava integraciju projekta te nagla\u0161ava potrebu za modernizacijom trenutnog API-ja Table AM. <\/p>\n
API Table AM ne name\u0107e izravno na\u010din implementacije MVCC-a. Me\u0111utim, API Table AM i API Index AM donose sljede\u0107i pretpostavak: svaki TID (Tuple\/row Identifier) ili je indeksiran svim indeksima ili uop\u0107e nije indeksiran. \u010cak i ako Index AM ima nekoliko referenci na jedan TID (na primjer, GIN), sve ove reference moraju odgovarati istom indeksiranom vrijednosti.
![\"Razvija\u010di](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nOva na\u010dela su kritizirana zbog pove\u0107anja broja operacija pisanja (\"write amplification\") \u2014 ako se a\u017eurira jedan indeksirani atribut, potrebno je a\u017eurirati svaki indeks u tablici. Da bi se u potpunosti iskoristile prednosti UNDO dnevnika ili izgradili druga\u010diji na\u010din pohrane bez \"poja\u010davanja pisanja\" (na primjer, WARM metoda), potrebno je prekr\u0161iti ovo pretpostavku.
![\"Razvija\u010di](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nTablica AM, temeljena na UNDO-u, koja ne\u0107e prekr\u0161iti ovu pretpostavku, podsje\u0107a na postoje\u0107u metodu HOT (Heap-Only Tuples), osim \u0161to se stare verzije redaka \u010duvaju u UNDO dnevniku i ne moraju stajati na istoj stranici. Me\u0111utim, prema autorima, ova prednost nije dovoljna da opravda postojanje odvojene Tablice AM. <\/p>\n
Prakti\u010dna ograni\u010denja postoje\u0107eg API-ja: <\/p>\n
- \n
- Tijekom a\u017euriranja reda tablice, indeksi se a\u017euriraju po na\u010delu \"sve ili ni\u0161ta\".\n
- Nedostatak API-ja Index AM za to\u010dno brisanje odre\u0111enih tuplea. Trenutno, tuple se mogu masovno brisati iz indeksa putem metoda ambulkdelete i amvacuumcleanup. Poku\u0161aj implementacije to\u010dnog brisanja putem ovog API-ja izazvao bi nisku u\u010dinkovitost, jer ve\u0107ina trenutnih implementacija mora skenirati cijeli indeks. Osim toga, API ne omogu\u0107uje navo\u0111enje koji od tuplea koji se odnose na isti TID treba izbrisati. Mo\u017ee izbrisati samo sve.\n
- Indeksi se trenutno odnose na redove tablice prema broju bloka (32 bita) i broju pomaka (16 bita). I samo 11 bita broja pomaka mo\u017ee se sigurno prenijeti iz TID tablice u sve metode pristupa indeksu. U tom slu\u010daju, alternativnim implementacijama MVCC mo\u017ee biti potrebno pohraniti dodatni korisni sadr\u017eaj (payload) zajedno s TID-om. Na primjer, u OrioleDB-u potrebno je jedan ili vi\u0161e bita za implementaciju indeksa za \"oznaku brisanja\" ili potpunih informacija o vidljivosti. <\/ul>\n
Predlo\u017eena su dva na\u010dina za prevladavanje ograni\u010denja u praksi: <\/p>\n
- \n
Pristup 1: API Index AM pru\u017ea mogu\u0107nosti za alternativnu implementaciju MVCC. <\/p>\n
Dok Table AM i dalje odgovara za sve komponente MVCC, Index AM pru\u017ea potrebne mogu\u0107nosti za alternativnu implementaciju MVCC, a to su: pohrana korisnog sadr\u017eaja (payload) zajedno s TID-om, metoda to\u010dnog brisanja i \u010dak metoda to\u010dnog a\u017euriranja (ako se TID u indeksu ne mo\u017ee promijeniti, korisni sadr\u017eaj \u2013 mo\u017ee). Osim toga, budu\u0107i da je potrebno dozvoliti vi\u0161e tuplica indeksa da upu\u0107uju na isti TID, metode API-ja koje se primjenjuju prilikom skeniranja indeksa tako\u0111er trebaju a\u017euriranje. <\/p>\n
Pristup 2: Indeksi koji podr\u017eavaju MVCC. <\/p>\n
Alternativa bi bila dozvoliti indeksima podr\u0161ku za MVCC. To jest, \"executor\" (ili, mo\u017eda, Table AM) jednostavno poziva metode insert() i delete() u Index AM-u, dok Index AM omogu\u0107ava skeniranje uzimaju\u0107i u obzir MVCC. To bi znatno pojednostavilo skeniranje koriste\u0107i samo indekse (index-only). \u010cak bi i cijeli Table AM u tom slu\u010daju mogao postati me\u0111usloj koji pohranjuje podatke u indeksu. <\/p>\n
Na dijagramu ispod je prikazan primjer. Vrijednost indeksa 2 a\u017eurira transakcija 11 s vrijednosti «A» na vrijednost «B». Stoga je vrijednost «A» ozna\u010dena kao xmax == 11, a vrijednost «B» ozna\u010dena kao xmin == 11. Tako se mo\u017ee skenirati indeks 2 i dobiti samo vidljive tuple u skladu s MVCC bez provjera hrpe. Prikupljanje sme\u0107a indeksa 2 tako\u0111er se mo\u017ee izvr\u0161iti bez kori\u0161tenja hrpe.
![\"Razvija\u010di](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nPri implementaciji svih navedenih noviteta u API indeksnih metoda pristupa, malo je vjerojatno da \u0107e se uspjeti istovremeno doraditi svi indeksi za podr\u0161ku svim novim mogu\u0107nostima. Realisti\u010dnije je omogu\u0107iti nekoliko implementacija za jednu indeksnu metodu pristupa. Na primjer, pored uobi\u010dajenog B-stabla, pro\u0161irenje \u0107e mo\u0107i implementirati alternativno B-stablo sa podr\u0161kom za MVCC unutar indeksa i podr\u0161kom za identifikatore zapisa proizvoljne duljine.
![\"Razvija\u010di](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n