Le modifiche necessarie all'API Table\/Index AM per supportare implementazioni alternative di MVCC vengono esaminate alla luce dell'estensione OrioleDB, sviluppata per risolvere i noti difetti del meccanismo di archiviazione integrato di PostgreSQL. Il problema \u00e8 che per una completa integrazione di OrioleDB con PostgreSQL \u00e8 necessario apportare modifiche al codice di PostgreSQL, il che complica l'implementazione del progetto e sottolinea la necessit\u00e0 di modernizzare l'attuale API Table AM. <\/p>\n
L'API Table AM non impone direttamente un metodo di implementazione del MVCC. Tuttavia, l'API Table AM e l'API Index AM fanno la seguente assunzione: ogni TID (Tuple\/row Identifier) \u00e8 o indicizzato da tutti gli indici, o non \u00e8 indicizzato affatto. Anche se l'Index AM ha pi\u00f9 riferimenti a un singolo TID (ad esempio, GIN), tutti questi riferimenti devono corrispondere a lo stesso valore indicizzato.
![\"Gli](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nQuesto principio \u00e8 stato criticato per l'aumento del numero di operazioni di scrittura (\u00abwrite amplification\u00bb) \u2014 se un attributo indicizzato viene aggiornato, \u00e8 necessario aggiornare ogni indice nella tabella. Per sfruttare appieno i vantaggi del journal UNDO o costruire un altro metodo di archiviazione senza \u00abamplificazione della scrittura\u00bb (ad esempio, il metodo WARM), \u00e8 necessario infrangere questa assunzione.
![\"Gli](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nLa Tabella AM basata su UNDO, che non viola questa assunzione, ricorda il metodo esistente HOT (Heap-Only Tuples), eccetto per il fatto che le versioni precedenti delle righe vengono conservate nel registro UNDO e non devono essere contenute nella stessa pagina. Tuttavia, gli autori ritengono che questo vantaggio non sia sufficiente a giustificare l'esistenza di una Tabella AM separata. <\/p>\n
Limitazioni pratiche dell'API esistente: <\/p>\n
- \n
- Durante l'aggiornamento di una riga della tabella, gli indici vengono aggiornati secondo il principio \u00abtutto o nulla\u00bb.\n
- Mancanza nell'API Index AM della possibilit\u00e0 di eliminazione puntuale di specifici tuple. Attualmente \u00e8 possibile eliminare tuple dagli indici in modo massiccio tramite i metodi ambulkdelete e amvacuumcleanup. Tentare di implementare un'eliminazione puntuale tramite questa API porterebbe a una bassa efficienza, poich\u00e9 la maggior parte delle implementazioni attuali deve eseguire una scansione dell'intero indice. Inoltre, l'API non consente di specificare quali delle tuple, che fanno riferimento allo stesso TID, debbano essere eliminate. Pu\u00f2 rimuovere solo tutte.\n
- Gli indici attualmente fanno riferimento alle righe della tabella tramite il numero di blocco (32 bit) e il numero di offset (16 bit). Solo 11 bit del numero di offset possono essere trasferiti in sicurezza dal TID della tabella a tutti i metodi di accesso all'indice. Le implementazioni alternative di MVCC potrebbero richiedere il salvataggio di un payload aggiuntivo insieme al TID. Ad esempio, in OrioleDB \u00e8 necessario uno o pi\u00f9 bit per implementare indici \u00abdelete-marking\u00bb o informazioni complete sulla visibilit\u00e0. <\/ul>\n
Sono stati proposti due modi per superare le limitazioni nella pratica: <\/p>\n
- \n
Approccio 1: L'API Index AM fornisce funzionalit\u00e0 per un'implementazione alternativa di MVCC. <\/p>\n
Mentre il Table AM continua a rispondere a tutti i componenti di MVCC, l'Index AM fornisce le funzionalit\u00e0 necessarie per una implementazione alternativa di MVCC, cio\u00e8: archiviazione di payload personalizzati insieme al TID, metodo di cancellazione punto per punto e persino metodo di aggiornamento punto per punto (se il TID nell'indice non pu\u00f2 essere modificato, il payload personalizzato pu\u00f2). Inoltre, poich\u00e9 \u00e8 necessario permettere a pi\u00f9 tuple dell'indice di fare riferimento allo stesso TID, i metodi API utilizzati durante la scansione dell'indice necessitano anch'essi di un aggiornamento. <\/p>\n
Approccio 2: Indici che supportano MVCC. <\/p>\n
Un'alternativa sarebbe consentire agli indici di supportare MVCC. Cio\u00e8, l'\u00abexecutor\u00bb (o, possibilmente, il Table AM) chiama semplicemente i metodi insert() e delete() nell'Index AM, mentre l'Index AM fornisce la possibilit\u00e0 di scansione tenendo conto di MVCC. Questo semplificherebbe notevolmente la scansione usando solo indici (index-only). Anche tutto il Table AM in tal caso potrebbe diventare uno strato intermedio che memorizza i dati nell'indice. <\/p>\n
Nel diagramma qui sotto \u00e8 riportato un esempio. Il valore dell'indice 2 viene aggiornato dalla transazione 11 da \"A\" a \"B\". Pertanto, il valore \"A\" \u00e8 contrassegnato come xmax == 11, mentre il valore \"B\" \u00e8 contrassegnato come xmin == 11. In questo modo \u00e8 possibile scansionare l'indice 2 e ottenere solo tuple visibili secondo MVCC senza controlli dell'heap. Anche la raccolta dei rifiuti dell'indice 2 pu\u00f2 essere eseguita senza utilizzare l'heap.
![\"Gli](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nCon l'introduzione di tutte le innovazioni elencate nell'API dei metodi di accesso agli indici, \u00e8 poco probabile che si riesca a rifinire contemporaneamente tutti gli indici per supportare tutte le nuove funzionalit\u00e0. \u00c8 pi\u00f9 realistico consentire diverse implementazioni per un metodo di accesso all'indice. Ad esempio, oltre al normale B-tree, l'estensione potrebbe implementare un B-tree alternativo con supporto MVCC all'interno dell'indice e supporto per identificatori di record di lunghezza arbitraria.
![\"Gli](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n