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

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

In response to

Browse pgsql-bugs by date

  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