From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | chris wood <chrisj(dot)wood(at)sympatico(dot)ca>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: question/suggestion Message-id: <493823B5.1030400@hogranch.com> |
Date: | 2008-12-07 06:26:47 |
Message-ID: | 493B6CA7.2090100@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
John R Pierce wrote:
> 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.
>
>
Objecting to an idea because it is difficult to implement is not
necessarily a clincher - there are projects trying to adapt Postgres to
more cloud-like capabilities (e.g Greenplum, Netezza) - neither of these
are open source however. There is also Pgcluster, however I'm not sure
that counts as cloud-like in its architecture...
regards
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-12-07 08:38:32 | Re: BUG #3818: Cross compilation problems |
Previous Message | Bruce Momjian | 2008-12-07 03:26:13 | Re: BUG #4186: set lc_messages does not work |