Skip to main content

One post tagged with "compatibility"

View All Tags

Bridged Indexes in OrioleDB: architecture, internals & everyday use?

· 4 min read
Alexander Korotkov
Alexander Korotkov
Creator of OrioleDB

Since version beta10 OrioleDB supports building indexes other than B-tree. Bridged indexes are meant to support these indexes on OrioleDB tables.

1. Why OrioleDB needs a “bridge”​

OrioleDB stores its table rows inside a B-tree built on a table primary key and keeps MVCC information in an undo log, so it can’t simply plug PostgreSQL’s existing Index Access Methods (GiST, GIN, SP-GiST, BRIN, …) into that structure. While PostgreSQL's Index Access Methods:

  • reference a 6-byte ctid (block number and offset in the heap) -- not a logical key;
  • keep every live version of a row in the index, leaving visibility checks to the executor;
  • support inserts only in the index and rely on VACUUM for physical deletion.

OrioleDB indexes, in contrast, are MVCC-aware: they point to the rows via primary-key values and support logical updates/deletes directly in the index. To remain heap-free while still allowing users build the rich ecosystem of non-B-tree indexes, OrioleDB introduces a bridge index layer.

Illustration of a bridge index