Granting it took Adobe about 10 years to switch from old classics API on mac to cocoa, don't expect CS on Ubuntu before 2050 if they start working on it today...
99 karma · joined November 16, 2016
The bigger the database the more complex it will be to implement schema change while keeping track of transactions that happen while your are transitioning. However I see no reason why it shouldn't be feasible given proper amount of preparation. And if short downtime is a goal I don't see why a proper amount of time developing a solution wouldn't make it either.
And on top of that PostgreSQL community is implementing new way to solve problem with each release. I'm not in a huge live-data use case so I might be wrong, but upcoming logical replication look promising for such use cases https://www.depesz.com/2017/02/07/waiting-for-postgresql-10-....
Distinguishing verifiable facts from marketing is actually important...
As for capability and reasonable aspect, I will be much more interested in reading post-mortem reports of the fatal crash under a truck by road safety organizations when (and if) they come out...
We must let go delusional thinking that with current AI we can safely throw autonomous car in a dense urban area.
Using autonomous car to improve mobility in rural area (eg. for elders people) would prove much more applicable as a paid service and complemental to public transportation.
But if mainstream geeks and investors keep dreaming about K2000 they will be deceived by current AI.
If i got this patch right, each partitioned table will have the same data structure and store whole rows (it's even more restrictive than previous inheritance mechanism that allowed extending by adding additional columns).
Column or expression should only define in which table an inserted row is supposed to be stored. A single row will never been torn apart. Still it look like a foundation that facilitate sharding BigData(Set) between multiple servers when used in conjunction with foreign data. However a lot of performance improvements will still be needed to compete against solid NoSQL projects (in which you really have a BigData use case).
But looking a bit forward, developing performances improvements on top of an ACID compliant distributed database seems less difficult than to develop a NoSQL project for it to become ACID.
Only recently did I realize that being focused on actual data and how to process it inside PostgreSQL was maybe the best way I could spend my working time. I really can't say what's the best part of PostgreSQL, the hyperactive community, the rock solid and clear documentation or the constant roll-out of efficient, non-disruptive, user-focused features...
Until now I was more investigating the native extension mechanism of PostgreSQL: https://www.postgresql.org/docs/current/static/extend-extens.... But I totally get that a more ad-hoc and versatile solution can be more fitted.
Don't be to rude because it's really minimalist, I actually just published this afternoon my first tiny test on GitHub here : https://github.com/MarHoff/Test
So i definitively had to say Hi there ;)