chris wood wrote:
At a detailed level (which is NOT the direction I want this thread to go) I do not agree with your statement that my proposal has no “hope of ACID compliance or transactional integrity”. When the “slices” are stored back to the cloud, this is the equivalent of a commit and the integrity thereof is as good as what ever the underlying technology is. Is the concurrency as good as native Postgres? Of course not. Is the commit/rollback flexibility as good as native Postgres? Again no. But what’s the alternative? Watch cloud computing take off leaving Postgres with the reputation of “great database software in yesterday’s era of monolithic servers”?
even something as simple as a SERIAL sequence would be a nightmare in a distributed cloud environment without a complex centralized arbitrer. the same goes for most any other sort of update/query that depends on consistency of data.
How do you reconcile a bank account when the money has been simultaneously withdrawn from several ATMs at different locations at the same time? "Please, sir, give us our money back?" ? I don't think the banks would be happy with that implementation.
If the data is partitioned across the cloud ('one version of the truth'), things like JOINs are very very difficult to implement efficiently. take away JOINs and you might as well be doing simple ISAM like we did back in the 70s before Codd and his Relational Database concepts upon which SQL is based.
no, IMHO, the cloud people are better off inventing their own data models and their own proprietary query languages suited to the architecture. maybe SQL and its concepts of 'one version of the truth' and 'data integrity' are quaint relics of another age, so be it.
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
