81–90 of 103 posts
Earlier quoted context omitted.
Greenplum Hadapt Netezza PipelineDb Postgres-XL Redshift AgensGraph TimescaleDB Fujitsu Enterprise Postgres PolarDB CrunchyBridge
Yugabyte
No commit history? It would have been interesting to follow the development work to see what changes they've made compared to PostgreSQL.
This is effectively required when open sourcing something that was previously internal. I've done it at a company. There could be company internal things that leak in old revisions of code and commit messages. Even if the latest commit on master is clean, it is really hard to know that every revisions, throughout the whole history is clean.
Earlier quoted context omitted.
Greenplum Hadapt Netezza PipelineDb Postgres-XL Redshift AgensGraph TimescaleDB Fujitsu Enterprise Postgres PolarDB CrunchyBridge
A quick note on Crunchy Bridge, it is pure Postgres, not "based" on Postgres. We haven't forked or modified code at all. And some of the above (Timescale) are extensions which do not change Postgres, but hook into the extension APIs.
The short-sightedness of forking boggles my mind every time. Oh, you don't want a team of hundreds of literally the best Postgres programmers in the world working for you full time all the time for free? Ok dude, have fun with your fork.
Earlier quoted context omitted.
Yugabyte
It has an API compatible with the postgresql wire protocol, but I don't think it fits in with the list since it doesn't share any code.
Earlier quoted context omitted.
This is effectively required when open sourcing something that was previously internal. I've done it at a company. There could be company internal things that leak in old revisions of code and commit messages. Even if the latest commit on master is clean, it is really hard to know that every revisions, throughout the whole history is clean.
Good point. In such a case, I think it would still be nice if at least trying to split the total change into a few separate commits, that builds upon each other. That way the commit log could be a good start to look at for someone who wants to understand the code base.
Looking at their code tree, this is based on 11.2 ( https://www.postgresql.org/docs/11/release-11-2.html ): https://github.com/alibaba/PolarDB-for-PostgreSQL/blob/maste... So this is code from two years ago missing stability fixes from upstream up to 11.12, at short sight.
Looks like it, yeah. Also, Postgres 12 introduced pluggable storage, which might help to implement a shared-nothing architecture without huge changes to vanilla Postgres (I haven't looked at how large their delta is)
It has worked for a long time without the need for Postgres 12. However, the new APIs introduced in v12 did enable us to offer columnar compression as an option, which complements a lot of scale-out use cases.
See: https://www.citusdata.com/blog/2021/03/06/citus-10-columnar-...
I believe using the extension facilities of Postgres is far superior to a fork in the medium to long term.
(Disclaimer: I work for Citus, and on columnar compression.)