As mudan\u00e7as necess\u00e1rias na API Table\/Index AM para dar suporte a implementa\u00e7\u00f5es alternativas de MVCC s\u00e3o discutidas com base na extens\u00e3o OrioleDB, criada para abordar as defici\u00eancias conhecidas do mecanismo de armazenamento embutido do PostgreSQL. O problema \u00e9 que, para uma integra\u00e7\u00e3o completa do OrioleDB com o PostgreSQL, s\u00e3o necess\u00e1rias altera\u00e7\u00f5es no c\u00f3digo do PostgreSQL, o que complica a implementa\u00e7\u00e3o do projeto e destaca a necessidade de moderniza\u00e7\u00e3o da API atual do Table AM. <\/p>\n
A API Table AM n\u00e3o imp\u00f5e diretamente a forma de implementa\u00e7\u00e3o do MVCC. No entanto, a API Table AM e a API Index AM fazem a seguinte suposi\u00e7\u00e3o: cada TID (Identificador de Tupla\/Linha) \u00e9 indexado por todos os \u00edndices ou n\u00e3o \u00e9 indexado de forma alguma. Mesmo que a Index AM tenha v\u00e1rias refer\u00eancias a um \u00fanico TID (por exemplo, GIN), todas essas refer\u00eancias devem corresponder ao mesmo valor indexado.
![\"Desenvolvedores](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nEste princ\u00edpio foi criticado pelo aumento do n\u00famero de opera\u00e7\u00f5es de escrita (\u00abwrite amplification\u00bb) \u2014 se um atributo indexado \u00e9 atualizado, cada \u00edndice na tabela precisa ser atualizado. Para aproveitar plenamente as vantagens do log UNDO ou construir um outro m\u00e9todo de armazenamento sem \u00abamplifica\u00e7\u00e3o de escrita\u00bb (por exemplo, o m\u00e9todo WARM), \u00e9 necess\u00e1rio violar essa suposi\u00e7\u00e3o.
![\"Desenvolvedores](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nA tabela AM baseada em UNDO, que n\u00e3o violar\u00e1 essa suposi\u00e7\u00e3o, \u00e9 semelhante ao m\u00e9todo HOT (Heap-Only Tuples), exceto que as vers\u00f5es antigas das linhas s\u00e3o mantidas no log UNDO e n\u00e3o precisam caber na mesma p\u00e1gina. No entanto, segundo os autores, essa vantagem n\u00e3o \u00e9 suficiente para justificar a exist\u00eancia de uma tabela AM separada. <\/p>\n
Limita\u00e7\u00f5es pr\u00e1ticas da API existente: <\/p>\n
- \n
- Durante a atualiza\u00e7\u00e3o de uma linha da tabela, os \u00edndices s\u00e3o atualizados com o princ\u00edpio de \u00abtudo ou nada\u00bb.\n
- A API Index AM n\u00e3o possui a capacidade de excluir determinados tuplos de forma pontual. Atualmente, \u00e9 poss\u00edvel excluir tuplos dos \u00edndices em massa atrav\u00e9s dos m\u00e9todos ambulkdelete e amvacuumcleanup. Tentar implementar uma exclus\u00e3o pontual atrav\u00e9s dessa API resultaria em baixa efici\u00eancia, uma vez que a maioria das implementa\u00e7\u00f5es atuais precisaria escanear todo o \u00edndice. Al\u00e9m disso, a API n\u00e3o permite especificar quais dos tuplos que referenciam o mesmo TID devem ser exclu\u00eddos. Ela pode excluir apenas todos eles.\n
- Os \u00edndices atualmente referenciam linhas da tabela pelo n\u00famero do bloco (32 bits) e pelo n\u00famero do deslocamento (16 bits). E somente 11 bits do n\u00famero do deslocamento podem ser transmitidos com seguran\u00e7a do TID da tabela para todos os m\u00e9todos de acesso ao \u00edndice. Nesse caso, implementa\u00e7\u00f5es alternativas de MVCC podem precisar armazenar uma carga \u00fatil adicional (payload) junto com o TID. Por exemplo, no OrioleDB, \u00e9 necess\u00e1rio um ou mais bits para implementar os \u00edndices de \u00abmarca\u00e7\u00e3o de dele\u00e7\u00e3o\u00bb ou informa\u00e7\u00f5es completas sobre visibilidade. <\/ul>\n
Foram propostos dois m\u00e9todos para superar as limita\u00e7\u00f5es na pr\u00e1tica: <\/p>\n
- \n
Abordagem 1: A API Index AM oferece possibilidades para a implementa\u00e7\u00e3o alternativa de MVCC. <\/p>\n
Enquanto o Table AM continua respons\u00e1vel por todos os componentes do MVCC, o Index AM fornece as capacidades necess\u00e1rias para a implementa\u00e7\u00e3o alternativa do MVCC, a saber: armazenamento de carga \u00fatil personalizada (payload) junto com o TID, m\u00e9todo de exclus\u00e3o pontual e at\u00e9 mesmo m\u00e9todo de atualiza\u00e7\u00e3o pontual (se o TID no \u00edndice n\u00e3o puder ser alterado, a carga \u00fatil personalizada pode). Al\u00e9m disso, como \u00e9 necess\u00e1rio permitir que v\u00e1rias tuplas do \u00edndice se refiram ao mesmo TID, os m\u00e9todos da API usados ao escanear o \u00edndice tamb\u00e9m precisam ser atualizados. <\/p>\n
Abordagem 2: \u00cdndices que suportam MVCC. <\/p>\n
Uma alternativa seria permitir que os \u00edndices suportassem MVCC. Ou seja, o \u00abexecutor\u00bb (ou, possivelmente, o Table AM) simplesmente chama os m\u00e9todos insert() e delete() no Index AM, enquanto o Index AM fornece a capacidade de escaneamento considerando o MVCC. Isso simplificaria significativamente o escaneamento usando apenas \u00edndices (index-only). Mesmo todo o Table AM, nesse caso, poderia se tornar uma camada intermedi\u00e1ria armazenando dados no \u00edndice. <\/p>\n
No diagrama abaixo \u00e9 apresentado um exemplo. O valor do \u00edndice 2 \u00e9 atualizado pela transa\u00e7\u00e3o 11 de «A» para «B». Portanto, o valor «A» \u00e9 marcado como xmax == 11, e o valor «B» \u00e9 marcado como xmin == 11. Assim, \u00e9 poss\u00edvel escanear o \u00edndice 2 e obter apenas as tuplas vis\u00edveis de acordo com o MVCC sem verifica\u00e7\u00f5es de heap. A coleta de lixo do \u00edndice 2 tamb\u00e9m pode ser realizada sem o uso de heap.
![\"Desenvolvedores](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nAo implementar todas as inova\u00e7\u00f5es listadas na API de m\u00e9todos de acesso a \u00edndices, \u00e9 improv\u00e1vel que seja poss\u00edvel atualizar todos os \u00edndices para suportar todas as novas capacidades simultaneamente. \u00c9 mais realista permitir v\u00e1rias implementa\u00e7\u00f5es para um m\u00e9todo de acesso a \u00edndice. Por exemplo, al\u00e9m do B-tree padr\u00e3o, a extens\u00e3o poder\u00e1 implementar um B-tree alternativo com suporte a MVCC dentro do \u00edndice e suporte a identificadores de registro de comprimento arbitr\u00e1rio.
![\"Desenvolvedores](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n