31–40 of 62 posts
Sensage/Addamark was too early to the columnar storage game in 2001-2003 ... https://en.wikipedia.org/wiki/Sensage .
There are other old column databases, such as kdb, but I believe Sybase/Expessway was the first commercial product.
Reassuring to see big new features like this coming out after the Microsoft acquisition, a healthy sign that this open source product continues to see serious ongoing investment.
Reassuring to see big new features like this coming out after the Microsoft acquisition, a healthy sign that this open source product continues to see serious ongoing investment.
well because they are the only cloud vendor with a HA master-master postgresql database (citusdb managed) it probably is also a selling point.
since we're talking postgresql: i recently started diving into postgresql and it seems to me that there is a patchwork of HA solutions (with patroni being the most feature-full) but no real multi-master solution for postgresql released under an open source license. There's BDR (bi-directional replication) but apparently 2ndquadrant pulled it back under a proprietary license, am i right? what's the current status of p…
true multi master is barely needed. but there is citus which uses the gpl, which can be run in multi master. and yes patroni is really really awesome.
Earlier quoted context omitted.
Came here to say this - I was looking to see how compression compared to timescale’s stated 91% compression. https://docs.timescale.com/latest/using-timescaledb/compress...
It always depends on the data, but we've seen 92.5% and more: https://twitter.com/JeffMealo/status/1368030569557286915
TimescaleDB users have seen 98% (ie over 50x) compression rates in some real-world cases (e.g., for some IT monitoring datasets), but compression ratio will definitely vary by dataset. (For example, a dataset of just 0s will compress even better! But that's probably not a realistic dataset :-) )
The reality is that Citus and TimescaleDB [0][1] take very different approaches to columnar compression, which result in different usability and performance trade-offs. In reality one should choose the right tool for their workload.
(As an aside, if you have time-series data, no one has spent more time developing an awesome time-series experience on Postgres than the TimescaleDB team has :-) )
Kudos to the Citus team for this launch! I love seeing how different members of the Postgres community keep pushing the state-of-the art.
[0] Building columnar compression in a row-oriented database (https://blog.timescale.com/blog/building-columnar-compressio...)
[1] Time-series compression algorithms, explained (https://blog.timescale.com/blog/time-series-compression-algo...)
Earlier quoted context omitted.
I think the claim here is that Citus added it to PostgreSQL. Depending on how one defines that claim, Greenplum may have been first. Disclosure: I work for VMware, which sponsors Greenplum development.
Greenplum was founded in 2003, A/S was 2001.
Earlier quoted context omitted.
I think the claim here is that Citus added it to PostgreSQL. Depending on how one defines that claim, Greenplum may have been first. Disclosure: I work for VMware, which sponsors Greenplum development.
Definitely not intending to take credit away from any other teams. There are so many good Postgres extensions and forks in this ecosystem. What we've done is add a Columnar storage feature into the Citus open source extension to Postgres, as part of Citus 10. One way to think of it: Citus 10 now gives Postgres users (those who are also using the Citus extension) a columnar compression option, for use on a single node…
Earlier quoted context omitted.
well because they are the only cloud vendor with a HA master-master postgresql database (citusdb managed) it probably is also a selling point.
Wait... they have 2 read/write masters? And you can read/write from either master at the same time?
Great start! Keep in mind the limitations: What are the Limitations? These limitations are not set in stone, and we look forward to working on them in the future: No UPDATE or DELETE support No index support No logical replication or logical decoding support See more limitations in the columnar README
cstore_fdw had the same limitations, so even if they say these limitations may not persist forever, i am not very hopeful they really want to solve this problem. But they could solve it with just a little bit of work: * Create a hidden bitmap information to store whether the „row“ of the columnar table is still valid * When updating/deleting values only set the bitmap information to zero to indicate the value is no l…
Great start! Keep in mind the limitations: What are the Limitations? These limitations are not set in stone, and we look forward to working on them in the future: No UPDATE or DELETE support No index support No logical replication or logical decoding support See more limitations in the columnar README
cstore_fdw had the same limitations, so even if they say these limitations may not persist forever, i am not very hopeful they really want to solve this problem. But they could solve it with just a little bit of work: * Create a hidden bitmap information to store whether the „row“ of the columnar table is still valid * When updating/deleting values only set the bitmap information to zero to indicate the value is no l…
Can you describe you use case for columnar update/delete in a little more detail? Is it a few random updates, or bulk updates, or something else?