Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The article makes some convincing arguments and the benchmarks seem to corroborate their performance claims, but I don't understand the dichotomy between this proposed new storage engine (OrioleDB?) and PostgreSQL itself.

Besides the commercial motivations and wanting to profit from the innovations discussed in the article, is there any reason why this needs to be a whole new database marketed as OrioleDB versus contributing these improvements upstream?



I'm seeing OrioleDB as a future engine for PostgreSQL. I'd like to see it as the default engine. However, the changes in OrioleDB are too big to be made incrementally. This is why I'm comparing the current PostgreSQL engine (with more than just heap, but many other subsystems as well) with OrioleDB.


Curious if you could share further roadmap. Potential interesting directions: 1. plans for integration with object store ala neon?

2. Columnar?

3. Async-io oriented redesign

4. Interesting new features ala subscriotions to table changes

5. Zero copy client bindings


Are there plans to build flashback-like functionality on top of Oriole DB? Being able to query data "as of xid" would be a great feature.


Just curious, are you ukrainian?

Never thought I would see a fellow ukrainian rewriting my fav db.


Alexander Korotkov (OrioleDb author) idea, - based on his Postgres committer experience, I believe, - is that these changes are way too big to be ever accepted upstream, hence separate engine. More info https://www.socallinuxexpo.org/sites/default/files/presentat..., see esp. slides 9-11


These changes are way too big to integrated into postgresql's engine itself. It fundamentally changes how MVCC is done.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: