Le modifiche necessarie all'API Table\/Index AM per supportare implementazioni MVCC alternative vengono esaminate tenendo in considerazione l'estensione OrioleDB, progettata per affrontare le note vulnerabilit\u00e0 del meccanismo di storage integrato di PostgreSQL. Il problema \u00e8 che per una piena integrazione di OrioleDB con PostgreSQL sono necessarie 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
API Table AM non impone direttamente come realizzare il MVCC. Tuttavia, l'API Table AM e l'API Index AM fanno la seguente assunzione: ogni TID (Tuple\/row Identifier) \u00e8 indicizzato da tutti gli indici o non \u00e8 indicizzato affatto. Anche se l'Index AM ha pi\u00f9 riferimenti a un TID (ad esempio, GIN), tutti questi riferimenti devono corrispondere allo 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 («write amplification») \u2014 se un attributo indicizzato viene aggiornato, \u00e8 necessario aggiornare ogni indice nella tabella. Per sfruttare appieno i vantaggi del log UNDO o costruire un altro metodo di archiviazione senza «amplificazione della scrittura» (ad esempio, il metodo WARM), \u00e8 necessario infrangere questa assunzione.
![\"Gli](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nUn Table AM basato su UNDO, che non violer\u00e0 questa assunzione, \u00e8 simile all'esistente metodo HOT (Heap-Only Tuples), tranne per il fatto che le vecchie versioni delle righe vengono mantenute nel log UNDO e non devono adattarsi nella stessa pagina. Tuttavia, secondo gli autori, questo vantaggio non \u00e8 sufficiente a giustificare l'esistenza di un Table AM separato. <\/p>\n
Restrizioni pratiche dell'attuale API: <\/p>\n
- \n
- Durante l'aggiornamento di una riga della tabella, gli indici vengono aggiornati secondo il principio «tutti o nulla».\n
- Mancanza di capacit\u00e0 nell'API Index AM per l'eliminazione mirata di specifici tuple. Attualmente \u00e8 possibile eliminare tuple dagli indici in modo massivo usando i metodi ambulkdelete e amvacuumcleanup. Tentare di implementare l'eliminazione mirata attraverso questo API porterebbe a un'elevata inefficienza, poich\u00e9 la maggior parte delle implementazioni attuali deve scansionare l'intero indice. Inoltre, l'API non consente di specificare quali tuple, che fanno riferimento allo stesso TID, dovrebbero essere eliminate. Pu\u00f2 solo eliminarle tutte.\n
- Gli indici fanno attualmente riferimento alle righe della tabella tramite un numero di blocco (32 bit) e un numero di offset (16 bit). Solo 11 bit del numero di offset possono essere trasmessi in modo sicuro dal TID della tabella a tutti i metodi di accesso dell'indice. Pertanto, implementazioni alternative di MVCC potrebbero necessitare di memorizzare un carico utile aggiuntivo (payload) insieme al TID. Ad esempio, in OrioleDB \u00e8 richiesto uno o pi\u00f9 bit per implementare gli indici «delete-marking» o informazioni complete sulla visibilit\u00e0. <\/ul>\n
Sono stati proposti due modi per superare le restrizioni nella pratica: <\/p>\n
- \n
Approccio 1: L'API Index AM fornisce possibilit\u00e0 per un'implementazione alternativa di MVCC. <\/p>\n
Mentre il Table AM continua a rispondere a tutti i componenti del MVCC, l'Index AM fornisce le funzionalit\u00e0 necessarie per un'implementazione alternativa del MVCC, ovvero: memorizzazione del carico utile personalizzato (payload) insieme al TID, metodo di cancellazione puntuale e persino metodo di aggiornamento puntuale (se il TID nell'indice non pu\u00f2 essere modificato, il carico utile personalizzato pu\u00f2). Inoltre, poich\u00e9 \u00e8 necessario consentire a pi\u00f9 tuple dell'indice di fare riferimento allo stesso TID, anche i metodi API utilizzati durante la scansione dell'indice necessitano di aggiornamento. <\/p>\n
Approccio 2: Indici che supportano MVCC. <\/p>\n
Un'alternativa sarebbe consentire agli indici di supportare il MVCC. Cio\u00e8, l'«executor» (o, forse, Table AM) semplicemente chiama i metodi insert() e delete() nell'Index AM, mentre l'Index AM fornisce la capacit\u00e0 di scansione tenendo conto del MVCC. Questo semplificherebbe notevolmente la scansione utilizzando solo indici (index-only). Anche l'intero Table AM in tal caso potrebbe diventare uno strato intermedio, memorizzando 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, e il valore «B» \u00e8 contrassegnato come xmin == 11. In questo modo \u00e8 possibile scansionare l'indice 2 e ottenere solo tuple visibili in base al MVCC senza controlli di heap (heap). La raccolta dei rifiuti dell'indice 2 pu\u00f2 anche essere eseguita senza l'uso della heap.
![\"Gli](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nCon l'implementazione di tutte le innovazioni elencate nell'API dei metodi di accesso agli indici, \u00e8 improbabile che si riesca a modificare contemporaneamente tutti gli indici per supportare tutte le nuove funzionalit\u00e0. \u00c8 pi\u00f9 realistico consentire diverse implementazioni per un singolo metodo di accesso all'indice. Ad esempio, oltre al consueto B-tree, l'estensione potrebbe implementare un B-tree alternativo con supporto per MVCC all'interno dell'indice e supporto per identificatori di registro di lunghezza variabile.
![\"Gli](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n