Les changements n\u00e9cessaires dans l'API Table\/Index AM pour prendre en charge des impl\u00e9mentations MVCC alternatives sont examin\u00e9s en tenant compte de l'extension OrioleDB, con\u00e7ue pour corriger les d\u00e9fauts connus du m\u00e9canisme de stockage int\u00e9gr\u00e9 de PostgreSQL. Le probl\u00e8me est que pour une int\u00e9gration compl\u00e8te d'OrioleDB avec PostgreSQL, des modifications du code de PostgreSQL sont n\u00e9cessaires, ce qui complique la mise en \u0153uvre du projet et souligne la n\u00e9cessit\u00e9 de moderniser l'API Table AM actuelle. <\/p>\n
L'API Table AM n'impose pas directement une m\u00e9thode d'impl\u00e9mentation du MVCC. Cependant, les API Table AM et Index AM font l'hypoth\u00e8se suivante : chaque TID (Tuple\/row Identifier) est soit index\u00e9 par tous les index, soit pas du tout. M\u00eame si l'Index AM a plusieurs r\u00e9f\u00e9rences \u00e0 un m\u00eame TID (par exemple, GIN), toutes ces r\u00e9f\u00e9rences doivent correspondre \u00e0 la m\u00eame valeur index\u00e9e.
![\"Les](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nCe principe a \u00e9t\u00e9 critiqu\u00e9 pour l'augmentation du nombre d'op\u00e9rations d'\u00e9criture (\u00ab write amplification \u00bb) \u2014 si un attribut index\u00e9 est mis \u00e0 jour, il est n\u00e9cessaire de mettre \u00e0 jour chaque index dans la table. Pour tirer pleinement parti du journal UNDO ou construire une autre m\u00e9thode de stockage sans \u00ab amplification d'\u00e9criture \u00bb (par exemple, la m\u00e9thode WARM), il faut remettre en question cette hypoth\u00e8se.
![\"Les](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nLa Table AM, fond\u00e9e sur UNDO, qui ne violera pas cette hypoth\u00e8se, ressemble \u00e0 la m\u00e9thode existante HOT (Heap-Only Tuples), \u00e0 l'exception que les anciennes versions des lignes sont conserv\u00e9es dans le journal UNDO et ne doivent pas tenir sur la m\u00eame page. Cependant, selon les auteurs, cet avantage n'est pas suffisant pour justifier l'existence d'une Table AM s\u00e9par\u00e9e. <\/p>\n
Limitations pratiques de l'API existante : <\/p>\n
- \n
- Lors de la mise \u00e0 jour d'une ligne de table, les index sont mis \u00e0 jour selon le principe \u00ab tout ou rien \u00bb.\n
- L'API Index AM ne permet pas la suppression cibl\u00e9e de certains tuples. Actuellement, les tuples peuvent \u00eatre supprim\u00e9s en masse des index \u00e0 l'aide des m\u00e9thodes ambulkdelete et amvacuumcleanup. Tenter de mettre en \u0153uvre la suppression cibl\u00e9e via cette API entra\u00eenerait une faible efficacit\u00e9, car la plupart des impl\u00e9mentations actuelles doivent scanner l'ensemble de l'index. De plus, l'API ne permet pas de sp\u00e9cifier quels tuples, se r\u00e9f\u00e9rant au m\u00eame TID, doivent \u00eatre supprim\u00e9s. Elle peut seulement les supprimer tous.\n
- Les index r\u00e9f\u00e9rencent actuellement les lignes de la table par num\u00e9ro de bloc (32 bits) et num\u00e9ro de d\u00e9calage (16 bits). Et seuls 11 bits du num\u00e9ro de d\u00e9calage peuvent \u00eatre transmis en toute s\u00e9curit\u00e9 du TID de la table vers toutes les m\u00e9thodes d'acc\u00e8s \u00e0 l'index. Dans ce contexte, des impl\u00e9mentations alternatives de MVCC peuvent n\u00e9cessiter le stockage d'une charge utile suppl\u00e9mentaire (payload) avec le TID. Par exemple, dans OrioleDB, un ou plusieurs bits sont n\u00e9cessaires pour impl\u00e9menter des index \u00ab delete-marking \u00bb ou des informations compl\u00e8tes sur la visibilit\u00e9. <\/ul>\n
Deux approches ont \u00e9t\u00e9 propos\u00e9es pour surmonter ces limitations en pratique : <\/p>\n
- \n
Approche 1 : L'API Index AM offre des possibilit\u00e9s pour une impl\u00e9mentation alternative de MVCC. <\/p>\n
Alors que Table AM continue d'\u00eatre responsable de tous les composants MVCC, Index AM fournit les capacit\u00e9s n\u00e9cessaires pour une impl\u00e9mentation alternative de MVCC, \u00e0 savoir : le stockage de charges utiles utilisateur (payload) avec le TID, la m\u00e9thode de suppression pr\u00e9cise et m\u00eame la m\u00e9thode de mise \u00e0 jour pr\u00e9cise (si le TID dans l'index ne peut pas \u00eatre modifi\u00e9, la charge utile utilisateur peut l'\u00eatre). En outre, \u00e9tant donn\u00e9 qu'il est n\u00e9cessaire de permettre \u00e0 plusieurs tuples de l'index de r\u00e9f\u00e9rencer le m\u00eame TID, les m\u00e9thodes API utilis\u00e9es lors du scan de l'index doivent \u00e9galement \u00eatre mises \u00e0 jour. <\/p>\n
Approche 2 : Index prenant en charge le MVCC. <\/p>\n
Une alternative serait de permettre aux index de prendre en charge le MVCC. Autrement dit, l'\u00ab executor \u00bb (ou, peut-\u00eatre, Table AM) appelle simplement les m\u00e9thodes insert() et delete() dans Index AM, tandis qu'Index AM fournit la possibilit\u00e9 de scan en tenant compte du MVCC. Cela simplifierait consid\u00e9rablement le scan en utilisant uniquement des index (index-only). M\u00eame tout le Table AM pourrait dans ce cas devenir une couche interm\u00e9diaire, stockant des donn\u00e9es dans l'index. <\/p>\n
Le diagramme ci-dessous pr\u00e9sente un exemple. La valeur de l'index 2 est mise \u00e0 jour par la transaction 11, passant de la valeur \u00ab A \u00bb \u00e0 la valeur \u00ab B \u00bb. Ainsi, la valeur \u00ab A \u00bb est marqu\u00e9e comme xmax == 11, tandis que la valeur \u00ab B \u00bb est marqu\u00e9e comme xmin == 11. Par cons\u00e9quent, on peut scanner l'index 2 et obtenir uniquement des tuples visibles selon le MVCC sans v\u00e9rifications de tas (heap). La collecte des d\u00e9chets de l'index 2 peut \u00e9galement \u00eatre effectu\u00e9e sans utiliser de tas.
![\"Les](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nLors de l'int\u00e9gration de toutes les innovations mentionn\u00e9es dans l'API des m\u00e9thodes d'acc\u00e8s aux index, il est peu probable que toutes les index puissent \u00eatre adapt\u00e9es en m\u00eame temps pour prendre en charge toutes les nouvelles fonctionnalit\u00e9s. Il est plus r\u00e9aliste de permettre plusieurs impl\u00e9mentations pour une m\u00e9thode d'acc\u00e8s d'index. Par exemple, en plus de l'arbre B ordinaire, l'extension pourrait mettre en \u0153uvre un arbre B alternatif avec prise en charge du MVCC \u00e0 l'int\u00e9rieur de l'index et prise en charge des identifiants d'enregistrement de longueur variable.
![\"Les](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n