\u00c6ndringerne, der er n\u00f8dvendige i API Table\/Index AM for at st\u00f8tte alternative implementeringer af MVCC, overvejes med henblik p\u00e5 OrioleDB-udvidelsen, der er udviklet for at im\u00f8deg\u00e5 de kendte mangler ved PostgreSQLs indbyggede lagermekanisme. Problemet er, at fuld integration af OrioleDB med PostgreSQL kr\u00e6ver \u00e6ndringer i PostgreSQL-koden, hvilket komplicerer projektets implementering og understreger behovet for modernisering af det nuv\u00e6rende API Table AM. <\/p>\n
API Table AM p\u00e5l\u00e6gger ikke direkte, hvordan MVCC skal implementeres. Ikke desto mindre antager API Table AM og API Index AM f\u00f8lgende: hver TID (Tuple\/row Identifier) er enten indekseret af alle indekser eller slet ikke indekseret. Selv hvis Index AM har flere referencer til en enkelt TID (f.eks. GIN), skal alle disse referencer matche den samme indekserede v\u00e6rdi.
![\"Udviklerne](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nDenne princip er blevet kritiseret for at \u00f8ge antallet af skriveoperationer (\u00bbwrite amplification\u00ab) \u2014 hvis \u00e9n indekseret attribut opdateres, skal hver index i tabellen opdateres. For fuldt ud at kunne udnytte fordelene ved en UNDO-log eller bygge en anden opbevaringsmetode uden \u00bbskriveforst\u00e6rkning\u00ab (for eksempel WARM-metoden) er det n\u00f8dvendigt at bryde dette antagelse.
![\"Udviklerne](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nTable AM, der er baseret p\u00e5 UNDO, som ikke vil overtr\u00e6de denne antagelse, minder om den eksisterende metode HOT (Heap-Only Tuples), bortset fra at gamle versioner af r\u00e6kker gemmes i UNDO-loggen og ikke skal v\u00e6re p\u00e5 samme side. Men if\u00f8lge forfatterne er dette fordele ikke tilstr\u00e6kkelige til at berettige eksistensen af en separat Table AM. <\/p>\n
Praktiske begr\u00e6nsninger i den eksisterende API: <\/p>\n
- \n
- Under opdateringen af en tabelr\u00e6kkes indekser opdateres efter princippet \u00bbalt eller intet\u00ab.\n
- Mangel p\u00e5 mulighed for punktvis sletning af bestemte tupler i API Index AM. I \u00f8jeblikket kan tupler kun slettes fra indekser massivt ved hj\u00e6lp af metoderne ambulkdelete og amvacuumcleanup. At fors\u00f8ge at implementere punktvis sletning via denne API ville f\u00f8re til lav effektivitet, da de fleste nuv\u00e6rende implementeringer skal scanne hele indekset. Desuden tillader API'et ikke at angive, hvilke af tuplerne, der refererer til den samme TID, der skal slettes. Det kan kun slette dem alle.\n
- Indekser refererer i \u00f8jeblikket til tabelr\u00e6kker ved bloknummer (32 bit) og forskydningsnummer (16 bit). Og kun 11 bit af forskydningsnummeret kan sikkert overf\u00f8res fra tabel TID til alle indeksadgangsmetoder. Dette kan medf\u00f8re, at alternative MVCC-implementeringer skal opbevare ekstra nyttelast (payload) sammen med TID. For eksempel kr\u00e6ver OrioleDB en eller flere bit til implementering af \u00bbdelete-marking\u00ab indekser eller fuld synlighedsinformation. <\/ul>\n
To metoder er foresl\u00e5et til at overvinde begr\u00e6nsningerne i praksis: <\/p>\n
- \n
Tilgang 1: API Index AM giver muligheder for alternativ implementering af MVCC. <\/p>\n
Mens Table AM fortsat er ansvarlig for alle MVCC-komponenter, tilbyder Index AM de n\u00f8dvendige funktioner til alternativ MVCC-implementering, nemlig: opbevaring af brugerens nyttelast (payload) sammen med TID, metode til punktfjerning og endda metode til punktopdatering (hvis TID i indekset ikke kan \u00e6ndres, kan brugerens nyttelast). Desuden, da det er n\u00f8dvendigt at tillade, at flere tuple i indekset refererer til samme TID, skal de anvendte API-metoder under indeksscan ogs\u00e5 opdateres. <\/p>\n
Tilgang 2: Indekser, der underst\u00f8tter MVCC. <\/p>\n
Et alternativ kunne v\u00e6re at tillade indekser, der underst\u00f8tter MVCC. Det vil sige, at \u00bbexecutor\u00ab (eller muligvis Table AM) simpelthen kalder metoderne insert() og delete() i Index AM, mens Index AM giver mulighed for scanning under hensyntagen til MVCC. Dette ville i h\u00f8j grad forsimple scanningen ved kun at bruge indekser (index-only). Selv hele Table AM i s\u00e5 fald kunne blive et mellemled, der opbevarer data i indekset. <\/p>\n
I diagrammet nedenfor er der et eksempel. Indeksv\u00e6rdien 2 opdateres af transaktionen 11 fra v\u00e6rdien «A» til v\u00e6rdien «B». Derfor er v\u00e6rdien «A» markeret som xmax == 11, og v\u00e6rdien «B» er markeret som xmin == 11. P\u00e5 denne m\u00e5de kan man scanne indeks 2 og f\u00e5 kun synlige tuples i overensstemmelse med MVCC uden at skulle kontrollere heapen. Affaldssamlingen af indeks 2 kan ogs\u00e5 udf\u00f8res uden brug af heapen.
![\"Udviklerne](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nVed implementeringen af alle de n\u00e6vnte innovationer i API'et for indeksmetoder til adgang, er det usandsynligt, at det er muligt at opdatere alle indekser samtidig for at underst\u00f8tte alle nye funktioner. Det er mere realistisk at tillade flere implementeringer for en tilgangsmetode til indeks. For eksempel, ud over den normale B-tree, vil udvidelsen kunne implementere en alternativ B-tree med st\u00f8tte for MVCC inden for indekset og st\u00f8tte for post-id'er af vilk\u00e5rlig l\u00e6ngde.
![\"Udviklerne](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n