Re: question/suggestion Message-id: <493823B5.1030400@hogranch.com> - Mailing list pgsql-bugs

From Mark Kirkwood
Subject Re: question/suggestion Message-id: <493823B5.1030400@hogranch.com>
Date
Msg-id 493B6CA7.2090100@paradise.net.nz
Whole thread Raw
In response to Re: question/suggestion Message-id: <493823B5.1030400@hogranch.com>  (John R Pierce <pierce@hogranch.com>)
List 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

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #4186: set lc_messages does not work
Next
From: Peter Eisentraut
Date:
Subject: Re: BUG #3818: Cross compilation problems