Die erforderlichen \u00c4nderungen an der API Table\/Index AM zur Unterst\u00fctzung alternativer Implementierungen von MVCC werden im Hinblick auf die OrioleDB-Erweiterung betrachtet, die entwickelt wurde, um bekannte Schw\u00e4chen des eingebauten Speichermechanismus von PostgreSQL zu beheben. Das Problem ist, dass f\u00fcr die vollst\u00e4ndige Integration von OrioleDB mit PostgreSQL \u00c4nderungen am PostgreSQL-Code erforderlich sind, was die Implementierung des Projekts erschwert und die Notwendigkeit der Modernisierung der aktuellen API Table AM unterstreicht. <\/p>\n
Die API Table AM zwingt nicht direkt eine bestimmte Implementierungsweise von MVCC auf. Dennoch geht die API Table AM und die API Index AM von folgender Annahme aus: Jeder TID (Tuple\/Row Identifier) wird entweder von allen Indizes indiziert oder gar nicht. Selbst wenn die Index AM mehrere Verweise auf einen TID hat (z. B. GIN), m\u00fcssen all diese Verweise den gleichen indizierten Wert entsprechen.
![\"Die](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nDieses Prinzip wurde kritisiert, da es die Anzahl der Schreibvorg\u00e4nge erh\u00f6ht (\u201eWrite Amplification\u201c) \u2014 wenn ein indexiertes Attribut aktualisiert wird, m\u00fcssen alle Indizes in der Tabelle aktualisiert werden. Um die Vorteile des UNDO-Logs voll auszusch\u00f6pfen oder eine andere Speichermethode ohne \u201eWrite Amplification\u201c (z. B. die WARM-Methode) zu entwickeln, ist es erforderlich, diese Annahme zu verletzen.
![\"Die](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nDie auf UNDO basierende Tabelle AM, die diese Annahme nicht verletzt, \u00e4hnelt der bestehenden HOT-Methode (Heap-Only Tuples), mit der Ausnahme, dass \u00e4ltere Versionen von Zeilen im UNDO-Log gespeichert werden und nicht auf derselben Seite untergebracht werden m\u00fcssen. Die Autoren sind jedoch der Meinung, dass dieser Vorteil nicht ausreicht, um die Existenz einer separaten Tabelle AM zu rechtfertigen. <\/p>\n
Praktische Einschr\u00e4nkungen der bestehenden API: <\/p>\n
- \n
- Beim Aktualisieren einer Tabellenzeile werden die Indizes nach dem Prinzip \u201ealles oder nichts\u201c aktualisiert.\n
- Im API Index AM fehlt die M\u00f6glichkeit, bestimmte Tupel gezielt zu l\u00f6schen. Derzeit k\u00f6nnen Tupel massenhaft mit den Methoden ambulkdelete und amvacuumcleanup aus Indizes entfernt werden. Ein Versuch, gezielte L\u00f6schungen \u00fcber diese API durchzuf\u00fchren, w\u00fcrde zu einer geringen Effizienz f\u00fchren, da die meisten aktuellen Implementierungen den gesamten Index scannen m\u00fcssen. Zudem erlaubt die API nicht anzugeben, welche der Tupel, die sich auf die gleiche TID beziehen, gel\u00f6scht werden sollen. Es kann nur alles entfernt werden.\n
- Indizes verweisen derzeit auf Tabellenzeilen durch die Blocknummer (32 Bit) und die Offsetnummer (16 Bit). Nur 11 Bit der Offsetnummer k\u00f6nnen sicher vom TID der Tabelle an alle Zugriffsverfahren des Index \u00fcbergeben werden. Dabei k\u00f6nnten alternative Implementierungen von MVCC zus\u00e4tzlichen Payload zusammen mit dem TID speichern m\u00fcssen. Beispielsweise ben\u00f6tigt OrioleDB ein oder mehrere Bits zur Implementierung von \u201eDelete-Marking\u201c-Indizes oder vollst\u00e4ndigen Sichtbarkeitsinformationen. <\/ul>\n
Zwei Ans\u00e4tze wurden vorgeschlagen, um die Einschr\u00e4nkungen in der Praxis zu \u00fcberwinden: <\/p>\n
- \n
Ansatz 1: Die API Index AM bietet M\u00f6glichkeiten f\u00fcr alternative MVCC-Implementierungen. <\/p>\n
W\u00e4hrend der Table AM weiterhin f\u00fcr alle Komponenten von MVCC verantwortlich ist, bietet der Index AM die erforderlichen Funktionen f\u00fcr alternative Implementierungen von MVCC, n\u00e4mlich: das Speichern von benutzerdefiniertem Payload zusammen mit TID, die Methode des punktuellen L\u00f6schens und sogar die Methode des punktuellen Aktualisierens (wenn TID im Index nicht ge\u00e4ndert werden kann, kann das benutzerdefinierte Payload jedoch ge\u00e4ndert werden). Dar\u00fcber hinaus m\u00fcssen die API-Methoden, die beim Scannen des Index angewendet werden, ebenfalls aktualisiert werden, da es mehreren Indizes erlaubt sein muss, auf dasselbe TID zu verweisen. <\/p>\n
Ansatz 2: Indizes, die MVCC unterst\u00fctzen. <\/p>\n
Eine Alternative w\u00e4re es, Indizes zuzulassen, die MVCC unterst\u00fctzen. Das hei\u00dft, der \u201eExecutor\u201c (oder m\u00f6glicherweise Table AM) ruft einfach die Methoden insert() und delete() im Index AM auf, w\u00e4hrend der Index AM die M\u00f6glichkeit des Scannens unter Ber\u00fccksichtigung von MVCC bietet. Dies w\u00fcrde das Scannen mit nur Indizes erheblich vereinfachen. Sogar der gesamte Table AM k\u00f6nnte in diesem Fall eine Zwischenschicht werden, die die Daten im Index speichert. <\/p>\n
In der folgenden Abbildung wird ein Beispiel dargestellt. Der Indexwert 2 wird von der Transaktion 11 von \u201eA\u201c auf \u201eB\u201c aktualisiert. Daher wird der Wert \u201eA\u201c als xmax == 11 markiert und der Wert \u201eB\u201c als xmin == 11. So kann man den Index 2 scannen und erh\u00e4lt nur die sichtbaren Tuple gem\u00e4\u00df MVCC ohne Heap-Pr\u00fcfungen. Die Bereinigung des Index 2 kann ebenfalls ohne Verwendung des Heaps durchgef\u00fchrt werden.
![\"Die](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nBei der Implementierung aller aufgef\u00fchrten Neuerungen in die API der indexierten Zugriffsverfahren ist es unwahrscheinlich, dass es gelingt, alle Indizes gleichzeitig anzupassen, um alle neuen Funktionen zu unterst\u00fctzen. Es ist realistischer, mehrere Implementierungen f\u00fcr eine Indexzugriffsmethode zuzulassen. Zum Beispiel wird das Erweiterungsmodul neben dem normalen B-Baum in der Lage sein, einen alternativen B-Baum mit Unterst\u00fctzung f\u00fcr MVCC innerhalb des Index und f\u00fcr identifizierbare Datens\u00e4tze beliebiger L\u00e4nge zu implementieren.
![\"Die](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n