https://www.postgresql.org/docs/current/ddl-constraints.html...

1) Overhead. SSI implies a heavyweight lock on any involved index page or heap tuple (even for reads). The overhead of SSI was initially measured at ~10%, but nowadays, scalability has gone much farther. These many HW-locks could slow down in multiple times a typical workload on a multicore machine.

2) SSI needs the user to be able to repeat any transaction due to serialization failure. Even a read-only transaction needs to be DEFERRABLE or might be aborted due to serialization failure (it might "saw impossible things" and needs a retry).

In contrast, typically it's not hard to resolve the concurrency problems of writing transactions using explicit row-level and advisory locks, while REPEATABLE READ is enough for reporting. Frankly speaking, during my whole career, I didn't see a single case where SERIALIZABLE isolation level was justified.

1. With PostgreSQL heap, you need to access the heap page itself. And it's not for free. It goes all through the buffer manager and other related components.

2. In OrioleDB, we have a lightweight protocol to read from pages. In-memory pages are connected using direct links (https://www.orioledb.com/docs/architecture/overview#dual-poi...), and pages are read lock-less (https://www.orioledb.com/docs/architecture/overview#page-str...). Additionally, tree navigation for simple data types skips both copying and tuple deforming (https://www.orioledb.com/blog/orioledb-fastpath-search).

According to all of the above, I believe OrioleDB still wins in the case of secondary key lookup. I think this is indirectly confirmed by the results of the TPC-C benchmark, which contains quite a lot of log of secondary key lookups. However, this subject is worth dedicated benchmarking in the future.

This blog post is dedicated to describing a new OrioleDB optimization: ordered insert optimization. When multiple processes are trying to insert into the same page, the first one that grabs the lock does the job for the others. That dramatically cuts the locker waiting time and thus improves the overall throughput. This is very critical for IoT, time series and others.

We would love for more people to test and benchmark OrioleDB. You can check how ordered insertion optimization would help your workload. The fastest way to do that is to use the Docker image provided (please note you need to use a specific tag):

    docker run -d --name orioledb -p 5432:5432 orioledb/orioledb:ordered-inserts-pg17

Comments URL: https://news.ycombinator.com/item?id=44950972

Points: 19

# Comments: 1

This blog post is dedicated to describing a new OrioleDB optimization: fastpath search, an inter-page search that bypasses page copying and tuple deformation for certain fixed-length datatypes.

We would love for more people to test and benchmark OrioleDB. You can check how fastpath search would help your workload. The fastest way to do that is to use the Docker image provided:

    docker run -d --name orioledb -p 5432:5432 orioledb/orioledb

Comments URL: https://news.ycombinator.com/item?id=44602093

Points: 4

# Comments: 1

We are getting closer to GA. This release includes:

- An index bridge to support all indexes that Heap supports

- Support for rewinding recent changes in the database.

- Tablespaces support

- Fillfactor support

- An orioledb_tree_stat() function for space utilization statistics

- Support for tables with more than 32 columns.

We also show several performance improvements using the TPC-C benchmarks. Overall, OrioleDB is much faster than Heap, also outperforming other Postgres providers.

We would love more people testing OrioleDB. The fastest way to do that is to use the docker image provided:

    docker run -d --name orioledb -p 5432:5432 orioledb/orioledb

https://www.orioledb.com/blog/orioledb-beta12-benchmarks

Comments URL: https://news.ycombinator.com/item?id=44570389

Points: 55

# Comments: 17

This is unrelated to NeonDB. OrioleDB has been acquired by Supabase. https://supabase.com/blog/supabase-acquires-oriole

Way more than just this!

> With some work you can run OrioleDB AND neon storage and get benefits of both.

This would require significant design work, given that significant OrioleDB benefits are derived from row-level WAL.

Comments URL: https://news.ycombinator.com/item?id=43615511

Points: 8

# Comments: 1

For sure, not all the PostgreSQL memory is N^2. AFAIR, just a couple of components, including deadlock decoding, require a quadratic amount of memory. Normally, they are insignificant but growing fast if you are rising max_connections.