De benodigde wijzigingen in de API Table\/Index AM voor de ondersteuning van alternatieve implementaties van MVCC worden besproken met het oog op de OrioleDB-extensie, die is ontwikkeld om de bekende tekortkomingen van de ingebouwde opslagmechanisme van PostgreSQL te verhelpen. Het probleem is dat voor een volledige integratie van OrioleDB met PostgreSQL aanpassingen aan de PostgreSQL-code vereist zijn, wat de implementatie van het project bemoeilijkt en de noodzaak benadrukt voor een modernisering van de huidige API Table AM. <\/p>\n
De API Table AM legt niet rechtstreeks een implementatiewijze van MVCC op. De API Table AM en de API Index AM maken echter de volgende veronderstelling: elk TID (Tuple\/row Identifier) is ofwel door alle indexen ge\u00efndexeerd, of helemaal niet ge\u00efndexeerd. Zelfs als de Index AM meerdere verwijzingen naar \u00e9\u00e9n TID heeft (bijvoorbeeld GIN), moeten al deze verwijzingen overeenkomen met dezelfde ge\u00efndexeerde waarde.
![\"De](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nDit principe is bekritiseerd vanwege de toename van schrijfoperaties (\u2018write amplification\u2019) \u2014 als een ge\u00efndexeerde eigenschap wordt bijgewerkt, moet elke index in de tabel worden bijgewerkt. Om volledig gebruik te maken van de voordelen van het UNDO-log of een andere opslagmethode zonder \u2018schrijfuitleg\u2019 (bijvoorbeeld de WARM-methode), moet deze aanname worden geschonden.
![\"De](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nDe Table AM, gebaseerd op UNDO, die deze veronderstelling niet zal schenden, lijkt op de bestaande HOT-methode (Heap-Only Tuples), met als enige verschil dat oude versies van rijen worden opgeslagen in het UNDO-logboek en niet op dezelfde pagina hoeven te passen. Doch, volgens de auteurs, is dit voordeel niet genoeg om het bestaan van een aparte Table AM te rechtvaardigen. <\/p>\n
Praktische beperkingen van de bestaande API: <\/p>\n
- \n
- Tijdens het bijwerken van een tabelrij worden de indexen bijgewerkt volgens het principe \u2018alles of niets\u2019.\n
- Het ontbreken van de mogelijkheid tot gerichte verwijdering van bepaalde tuples in de API Index AM. Momenteel kunnen tuples massaal uit indexen worden verwijderd met behulp van de methodes ambulkdelete en amvacuumcleanup. Pogingen om gerichte verwijdering via deze API te implementeren zouden leiden tot lage effici\u00ebntie, aangezien de meeste huidige implementaties de hele index moeten doorzoeken. Bovendien staat de API niet toe om aan te geven welke van de tuples, die naar dezelfde TID verwijzen, moeten worden verwijderd. Het kan alleen ze allemaal verwijderen.\n
- Indexen verwijzen momenteel naar tabelrijen op basis van het bloknummer (32 bits) en het offsetnummer (16 bits). Van het offsetnummer kunnen slechts 11 bits veilig worden overgedragen van de tabel TID naar alle indextoegangsmethoden. Alternatieve MVCC-implementaties kunnen echter extra payload samen met de TID moeten opslaan. Bijvoorbeeld, in OrioleDB zijn \u00e9\u00e9n of meerdere bits vereist voor de implementatie van \u2018delete-marking\u2019 indexen of volledige zichtbaarheidinformatie. <\/ul>\n
Twee manieren zijn voorgesteld om de beperkingen in de praktijk te overwinnen: <\/p>\n
- \n
Aanpak 1: API Index AM biedt mogelijkheden voor alternatieve implementatie van MVCC. <\/p>\n
Terwijl Table AM verantwoordelijk blijft voor alle componenten van MVCC, biedt Index AM de noodzakelijke mogelijkheden voor alternatieve MVCC-implementaties, namelijk: het opslaan van aangepaste payload samen met TID, een methode voor puntverwijdering en zelfs een methode voor puntbijwerking (indien TID in de index niet kan worden gewijzigd, kan de aangepaste payload dat wel). Bovendien, omdat het nodig is dat meerdere tuples van de index naar dezelfde TID verwijzen, moeten ook de API-methoden die worden toegepast tijdens het indexscannen worden bijgewerkt. <\/p>\n
Aanpak 2: Indexen die MVCC ondersteunen. <\/p>\n
Een alternatief zou zijn om indexen toe te staan die MVCC ondersteunen. Dat wil zeggen, de \u2018executor\u2019 (of mogelijk Table AM) roept eenvoudigweg de insert() en delete() methoden aan in Index AM, terwijl Index AM de mogelijkheid biedt om te scannen met MVCC in gedachten. Dit zou het scannen met alleen indexen aanzienlijk eenvoudiger maken. Zelfs de hele Table AM zou in dit geval een tussenlaag kunnen worden die gegevens in de index opslaat. <\/p>\n
In de onderstaande diagram is een voorbeeld weergegeven. De waarde van index 2 wordt bijgewerkt door transactie 11 van waarde «A» naar waarde «B». Daarom wordt waarde «A» gemarkeerd als xmax == 11, en waarde «B» als xmin == 11. Op deze manier kan index 2 gescand worden om alleen zichtbare tuples te verkrijgen volgens MVCC zonder heap-controles. Het opruimen van index 2 kan ook worden uitgevoerd zonder gebruik te maken van de heap.
![\"De](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nBij het implementeren van alle genoemde vernieuwingen in de API van index-accessmethoden, is het onwaarschijnlijk dat het mogelijk zal zijn om alle indexen gelijktijdig aan te passen om alle nieuwe mogelijkheden te ondersteunen. Het is realistischer om verschillende implementaties voor \u00e9\u00e9n index-accessmethode toe te staan. Bijvoorbeeld, naast de gebruikelijke B-tree, kan de extensie een alternatieve B-tree implementeren met ondersteuning voor MVCC binnen de index en ondersteuning voor record-identificatoren van variabele lengte.
![\"De](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n