De f\u00f6r\u00e4ndringar som kr\u00e4vs i API Table\/Index AM f\u00f6r att st\u00f6dja alternativa implementeringar av MVCC \u00f6verv\u00e4gs med h\u00e4nsyn till OrioleDB-utvidgningen, som utvecklats f\u00f6r att \u00e5tg\u00e4rda k\u00e4nda brister i den inbyggda lagringsmekanismen i PostgreSQL. Problemet \u00e4r att fullst\u00e4ndig integration av OrioleDB med PostgreSQL kr\u00e4ver \u00e4ndringar i PostgreSQL-koden, vilket komplicerar projektets genomf\u00f6rande och understryker behovet av att modernisera det nuvarande API:et f\u00f6r Table AM. <\/p>\n
API Table AM p\u00e5tvingar inte direkt hur MVCC ska implementeras. \u00c4nd\u00e5 g\u00f6r API Table AM och API Index AM f\u00f6ljande antagande: varje TID (Tuple\/row Identifier) antingen indexeras av alla index eller inte indexeras alls. \u00c4ven om Index AM har flera referenser till en TID (till exempel GIN), m\u00e5ste alla dessa referenser \u00f6verensst\u00e4mma med samma indexerade v\u00e4rde.
![\"Utvecklarna](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nDenna princip har kritiserats f\u00f6r att \u00f6ka antalet skrivoperationer (\"write amplification\") \u2014 om en indexerad attribut uppdateras m\u00e5ste varje index i tabellen uppdateras. F\u00f6r att kunna utnyttja f\u00f6rdelarna med UNDO-loggen fullt ut eller bygga en annan lagringsmetod utan \"skrivf\u00f6rst\u00e4rkning\" (till exempel WARM-metoden) kr\u00e4vs det att denna f\u00f6ruts\u00e4ttning bryts.
![\"Utvecklarna](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nTabell AM, baserad p\u00e5 UNDO, kommer inte att bryta mot denna f\u00f6ruts\u00e4ttning och liknar den befintliga metoden HOT (Heap-Only Tuples), f\u00f6rutom att gamla versioner av rader sparas i UNDO-loggen och inte beh\u00f6ver f\u00e5 plats p\u00e5 samma sida. Men enligt f\u00f6rfattarna \u00e4r denna f\u00f6rdel inte tillr\u00e4cklig f\u00f6r att r\u00e4ttf\u00e4rdiga existensen av en separat Table AM. <\/p>\n
Praktiska begr\u00e4nsningar med det befintliga API:et: <\/p>\n
- \n
- Vid uppdatering av rader i tabellen uppdateras indexen enligt principen \"allt eller inget\".\n
- Avsaknad av API Index AM f\u00f6r m\u00f6jligheten att punktligt ta bort specifika tuples. F\u00f6r n\u00e4rvarande kan tuples tas bort fr\u00e5n index massivt med metoderna ambulkdelete och amvacuumcleanup. Att f\u00f6rs\u00f6ka implementera punktvis borttagning genom detta API skulle leda till l\u00e5g effektivitet, eftersom de flesta nuvarande implementationer m\u00e5ste skanna hela indexet. Dessutom till\u00e5ter API:et inte att ange vilka av de tuples som refererar till samma TID som ska tas bort. Det kan endast ta bort dem alla.\n
- Indexen refererar f\u00f6r n\u00e4rvarande till rader i tabellen med blocknummer (32 bitar) och offset-nummer (16 bitar). Endast 11 bitar av offset-numret kan s\u00e4kert \u00f6verf\u00f6ras fr\u00e5n TID-tabellen till alla index\u00e5tkomstmetoder. Detta kan kr\u00e4va att alternativa implementationer av MVCC lagrar extra nyttolast (payload) tillsammans med TID. Till exempel kr\u00e4ver OrioleDB en eller flera bitar f\u00f6r att implementera index med \"delete-marking\" eller fullst\u00e4ndig synlighetsinformation. <\/ul>\n
Tv\u00e5 s\u00e4tt har f\u00f6reslagits f\u00f6r att \u00f6vervinna begr\u00e4nsningarna i praktiken: <\/p>\n
- \n
Tillv\u00e4gag\u00e5ngss\u00e4tt 1: API Index AM tillhandah\u00e5ller m\u00f6jligheter f\u00f6r alternativ MVCC-implementering. <\/p>\n
Medan Table AM forts\u00e4tter att ansvara f\u00f6r alla komponenter av MVCC, erbjuder Index AM n\u00f6dv\u00e4ndiga funktioner f\u00f6r alternativ implementation av MVCC, n\u00e4mligen: lagring av anv\u00e4ndarnyttolast (payload) tillsammans med TID, punktborttagningsmetod och till och med punktuppdateringsmetod (om TID i indexet inte kan \u00e4ndras, kan nyttolasten \u00e4ndras). Dessutom, eftersom flera tuple i indexet m\u00e5ste referera till samma TID, beh\u00f6ver API-metoderna som anv\u00e4nds vid indexskanning ocks\u00e5 uppdateras. <\/p>\n
Tillv\u00e4gag\u00e5ngss\u00e4tt 2: Index som st\u00f6djer MVCC. <\/p>\n
Ett alternativ skulle vara att till\u00e5ta index som st\u00f6djer MVCC. Det vill s\u00e4ga att \"executor\" (eller kanske Table AM) helt enkelt anropar metoderna insert() och delete() i Index AM, medan Index AM erbjuder m\u00f6jligheten att skanna med h\u00e4nsyn till MVCC. Detta skulle avsev\u00e4rt f\u00f6renkla skanning med endast index (index-only). Till och med hela Table AM skulle i s\u00e5dana fall kunna fungera som ett mellanlager som lagrar data i indexet. <\/p>\n
I diagrammet nedan visas ett exempel. Indexv\u00e4rdet 2 uppdateras av transaktionen 11 fr\u00e5n v\u00e4rdet «A» till v\u00e4rdet «B». D\u00e4rf\u00f6r \u00e4r v\u00e4rdet «A» markerat som xmax == 11, och v\u00e4rdet «B» \u00e4r markerat som xmin == 11. P\u00e5 s\u00e5 s\u00e4tt kan index 2 skannas och endast synliga tuples h\u00e4mtas i enlighet med MVCC utan att beh\u00f6va kontrollera heapen. Skr\u00e4pplockning av index 2 kan ocks\u00e5 utf\u00f6ras utan att anv\u00e4nda heapen.
![\"Utvecklarna](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nVid implementeringen av alla de n\u00e4mnda nyheterna i API:et f\u00f6r indexmetoder \u00e4r det osannolikt att det g\u00e5r att samtidigt revidera alla index f\u00f6r att st\u00f6dja alla nya funktioner. Det \u00e4r mer realistiskt att till\u00e5ta flera implementationer f\u00f6r en indexmetod. Till exempel, ut\u00f6ver den vanliga B-tree, kan utvidgningen implementera en alternativ B-tree med st\u00f6d f\u00f6r MVCC inuti indexet och st\u00f6d f\u00f6r postidentifierare av godtycklig l\u00e4ngd.
![\"Utvecklarna](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n