Comment by wokwokwok | Hacker News Reader

Comment by wokwokwok | Hacker News Reader

Good job! That's cool.

How do you plan to make your new project keep up to date with the release cadence of the parent project?

...because otherwise, I can't see how this is a good idea.

Look, I have the same reaction whenever someone does this.

If someone goes and forks rust and creates a new programming language call dust that solves I dunno, the fundamental async compatibility story, or adds (somehow) a zero cost native GC type back into the language, I'd say the same thing.

You've taken a big open source project, forked it and laid some significant changes on it, which you don't believe this be accepted upstream.

Ok...is this a toy that you made for fun?

...or a serious project you expect to maintain?

If the answer is 'serious project', please make explicit your plans to avoid becoming abandonware in the future, your plans to fold future release from (original project) into yours, or your plans to diverge henceforth into an entirely new project.

To be fair, I get it, this is an extension that seems like it could... probably... receive changes that are made upstream in postgres; but, if it was that easy, it belongs as part of the postgres projecct; so, I guess, it's not that easy.

So, serious? Or just for fun?

The author wrote this, answering the question in a reply on the post:

> Yes, sure! But that's the long way to go. Right now OrioleDB is an extension, which comes with PostgreSQL core patch. The mid-term goal for OrioleDB is to become a pure extension. The long-term goal is to make OrioleDB part of PostgreSQL core.

> The long-term goal is to make OrioleDB part of PostgreSQL core.

That would be really the perfect outcome

are you considering using this in production somewhere in the next few days? your reply comes off as absurdly aggressive, especially when you mention no intention of supporting the project monetarily. and that's on top of this question being addressed already, as other commenters pointed out.

maybe don't come in so hot next time.

It could likely have been better phrased but I found it more pointed than aggressive.

There've been quite a few postgres forks that have either died or stayed based on 7.x versions and when you're replacing the entire storage engine - and hence also the on-disk format - migrating away from it if circumstances require it later is going to be annoyingly non-trivial.

So while I think I agree with "don't come in so hot", "absurdly aggressive" may nonetheless be over-egging it slightly given the context.

OrioleDB is based on earlier work done in the core Postgres to introduce a storage extension framework called Table Access Methods.

This phase adds significant enhancements to make the OrioleDB extension feasible and aggressively performant.. and the delta code to be committed upstream is less than 2K LOC.

Comparing this project to earlier forks that got stuck at 7.x and 8.x would be a huge disservice to the maturity and extensibility of the Postgres project.

On your latter point, OrioleDB does not “replace” the built-in storage engine (which works quite well for many many use-cases), it “augments” the core capabilities with an additional storage engine optimised for many use-cases where the legacy engine struggles.

HTH

> .. and the delta code to be committed upstream is less than 2K LOC.

Then mainline it?

The last commit that /postgres/postgres and /orioledb/postgres share (1) is 6 months old for 15.2?

I mean, this is literally what I'm pointing out in my comment; you're chasing a moving target. Every change postgres makes, you have to merge in check it doesn't conflict, roll out a new patch set...

...and, you're already falling behind on it.

So, going forward, how do you plan to keep up to date...? ...because it looks to me, like a < 2K LOC isn't a fix for this problem; it hasn't solved it for you, as time goes forwards, it will continue not to be a solution to the problem; annd...

> Currently the changes needed to Postgres core are less than a 1000 lines of code. Due to the separate development schedules for Postgres and OrioleDB, these changes cannot be unstreamed in time for v.15. (2)

^ They were < 1000 lines a year ago, apparently. So the problem is getting worse over time.

Seems like the solution is mainlining those changes... not just intending to mainline them.

Until then... I really just see this as a postgres fork.

[1] - https://github.com/postgres/postgres/commit/78ec02d612a9b690... vs https://github.com/orioledb/postgres/commit/78ec02d612a9b690...

[2] - https://github.com/orioledb/postgres/issues/2

As a data point, that's already been answered: :)

https://news.ycombinator.com/item?id=36742001

Reasonable points. As an onlooker who has run into VACUUM in years past, I have wondered: is this a fundamental necessity, or could it possibly be fixed? Seeing an example of it being fixed is certainly helpful. If I work at a company with the resources to maintain a Postgres fork, great! If not, we can evaluate whether the challenges of using this fork are worth the performance benefit.

> a company with the resources to maintain a Postgres fork

That sounds like a monumental feat

monumental? OrioleDB works anywhere where you are running your own self-managed Postgres instance.. be it on bare-metal, or VMs, or EC2.

this is NOT a new database

Reply on news.ycombinator.com