Los cambios necesarios en la API de Table\/Index AM para admitir implementaciones alternativas de MVCC se consideran a la luz de la extensi\u00f3n OrioleDB, dise\u00f1ada para abordar las limitaciones conocidas del mecanismo de almacenamiento integrado en PostgreSQL. El problema es que para la integraci\u00f3n completa de OrioleDB con PostgreSQL se requieren modificaciones en el c\u00f3digo de PostgreSQL, lo que complica la implementaci\u00f3n del proyecto y subraya la necesidad de modernizar la API actual de Table AM. <\/p>\n
La API de Table AM no impone directamente la forma de implementaci\u00f3n de MVCC. Sin embargo, la API de Table AM y la API de Index AM hacen la siguiente suposici\u00f3n: cada TID (Identificador de Tupla\/Fila) o est\u00e1 indexado por todos los \u00edndices o no est\u00e1 indexado en absoluto. Incluso si la Index AM tiene m\u00faltiples referencias a un mismo TID (por ejemplo, GIN), todas estas referencias deben corresponder al mismo valor indexado.
![\"Los](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nEste principio ha sido criticado por aumentar el n\u00famero de operaciones de escritura («write amplification») — si se actualiza un atributo indexado, es necesario actualizar cada \u00edndice en la tabla. Para aprovechar completamente las ventajas del registro UNDO o construir otro m\u00e9todo de almacenamiento sin «amplificaci\u00f3n de escritura» (como el m\u00e9todo WARM), es necesario romper esta suposici\u00f3n.
![\"Los](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nLa Tabla AM, basada en UNDO, que no violar\u00e1 esta suposici\u00f3n, se asemeja al m\u00e9todo existente HOT (Heap-Only Tuples), excepto que las versiones antiguas de las filas se mantienen en el registro UNDO y no deben caber en la misma p\u00e1gina. Sin embargo, seg\u00fan los autores, esta ventaja no es suficiente para justificar la existencia de una Tabla AM separada. <\/p>\n
Limitaciones pr\u00e1cticas de la API existente: <\/p>\n
- \n
- Durante la actualizaci\u00f3n de una fila de tabla, los \u00edndices se actualizan bajo el principio de «todo o nada».\n
- La API Index AM actualmente no permite la eliminaci\u00f3n puntual de ciertos tuplas. Actualmente, las tuplas se pueden eliminar masivamente de los \u00edndices mediante los m\u00e9todos ambulkdelete y amvacuumcleanup. Intentar implementar la eliminaci\u00f3n puntual a trav\u00e9s de esta API llevar\u00eda a una baja eficiencia, ya que la mayor\u00eda de las implementaciones actuales deben escanear todo el \u00edndice. Adem\u00e1s, la API no permite especificar cu\u00e1les de las tuplas que hacen referencia a un mismo TID deben eliminarse. Solo puede eliminar todas ellas.\n
- Los \u00edndices actualmente hacen referencia a las filas de la tabla por n\u00famero de bloque (32 bits) y n\u00famero de desplazamiento (16 bits). Y solo 11 bits del n\u00famero de desplazamiento se pueden transmitir de manera segura desde el TID de la tabla a todos los m\u00e9todos de acceso al \u00edndice. En este sentido, las implementaciones alternativas de MVCC pueden requerir almacenar una carga adicional (payload) junto con el TID. Por ejemplo, en OrioleDB se requiere uno o varios bits para implementar \u00edndices de «marcado de eliminaci\u00f3n» o informaci\u00f3n completa de visibilidad. <\/ul>\n
Se han propuesto dos enfoques para superar las limitaciones en la pr\u00e1ctica: <\/p>\n
- \n
Enfoque 1: La API Index AM proporciona capacidades para una implementaci\u00f3n alternativa de MVCC. <\/p>\n
Mientras que el Table AM sigue siendo responsable de todos los componentes de MVCC, el Index AM proporciona las capacidades necesarias para una implementaci\u00f3n alternativa de MVCC, a saber: almacenamiento de carga \u00fatil (payload) del usuario junto con el TID, m\u00e9todo de eliminaci\u00f3n puntual e incluso m\u00e9todo de actualizaci\u00f3n puntual (si el TID en el \u00edndice no puede ser cambiado, la carga \u00fatil del usuario – s\u00ed puede). Adem\u00e1s, dado que es necesario permitir que m\u00faltiples tuplas del \u00edndice hagan referencia al mismo TID, los m\u00e9todos de API utilizados al escanear el \u00edndice tambi\u00e9n necesitan actualizaci\u00f3n. <\/p>\n
Enfoque 2: \u00cdndices que admiten MVCC. <\/p>\n
Una alternativa ser\u00eda permitir que los \u00edndices soporten MVCC. Es decir, el «executor» (o, posiblemente, Table AM) simplemente llama a los m\u00e9todos insert() y delete() en Index AM, mientras que Index AM proporciona la capacidad de escaneo teniendo en cuenta MVCC. Esto simplificar\u00eda significativamente el escaneo utilizando solo \u00edndices (index-only). Incluso todo el Table AM en tal caso podr\u00eda convertirse en una capa intermedia que almacena datos en el \u00edndice. <\/p>\n
El diagrama a continuaci\u00f3n muestra un ejemplo. El valor del \u00edndice 2 se actualiza con la transacci\u00f3n 11 de «A» a «B». Por lo tanto, el valor «A» se marca como xmax == 11, y el valor «B» se marca como xmin == 11. As\u00ed, se puede escanear el \u00edndice 2 y obtener \u00fanicamente las tuplas visibles de acuerdo con MVCC sin realizar verificaciones de montones (heap). La recolecci\u00f3n de basura del \u00edndice 2 tambi\u00e9n se puede llevar a cabo sin utilizar un mont\u00f3n.
![\"Los](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nAl implementar todas las innovaciones mencionadas en la API de los m\u00e9todos de acceso indexados, es poco probable que se logre mejorar todos los \u00edndices para soportar todas las nuevas funcionalidades al mismo tiempo. Es m\u00e1s realista permitir varias implementaciones para un solo m\u00e9todo de acceso de \u00edndice. Por ejemplo, adem\u00e1s del B-tree est\u00e1ndar, la extensi\u00f3n podr\u00e1 implementar un B-tree alternativo que soporte MVCC dentro del \u00edndice y soporte identificadores de registro de longitud variable.
![\"Los](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n