OrioleDB isn't a separation of storage and compute, its a more efficient storage engine for Postgres to replace the existing HEAP engine. This is like how in MySQL we could swap MyISAM for InnoDB and eventually RocksDB.
I did some benchmarks on it previously to show how much of an improvement it gives over the stock HEAP engine
EDIT: correct link to the public dashboard below, thanks for the heads up @kiwicopple
"Bridged Indexes" is a non-standard term. These are just secondary indexes using logical pointers with a mapping index. IIRC, Oracle, Hana, and HyPer do the same thing.
The CMU paper indicates the logical keys are either TupleID or Primary Key, while the bridged index is actually a TupleID that resolves to a Primary Key, which resolves to the actual tuple - one more level than indicated by 6.1's explanation of logical pointers.
Readit News
I did some benchmarks on it previously to show how much of an improvement it gives over the stock HEAP engine
EDIT: correct link to the public dashboard below, thanks for the heads up @kiwicopple
https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N
https://www.orioledb.com/docs/usage/decoupled-storage
https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N
thanks for running the benchmarks, it helps to have external parties verifying the progress
Althoug with them being recently acquired by Databricks it remains to be seen how the open source version will fare.
This is unrelated to NeonDB. OrioleDB has been acquired by Supabase. https://supabase.com/blog/supabase-acquires-oriole
Source: https://db.cs.cmu.edu/papers/2017/p781-wu.pdf (see Table 1 + Section 6.1)
rolls off the tongue.
The CMU paper indicates the logical keys are either TupleID or Primary Key, while the bridged index is actually a TupleID that resolves to a Primary Key, which resolves to the actual tuple - one more level than indicated by 6.1's explanation of logical pointers.
Dead Comment