Reply-To: <andy@areyoulocal.co.uk>
From: "Andy Ballingall" <andy@areyoulocal.co.uk>
To: "'David Roussel'" <pgsql-performance@diroussel.xsmail.com>
Cc: <pgsql-performance@postgresql.org>
Subject: Re: 2 phase commit: performance implications?
Date: Wed, 21 Dec 2005 12:10:53 -0000
Organization: Areyoulocal Ltd.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <43A81C8E.6010602@diroussel.xsmail.com>
Thread-Index: AcYFdkuksrhPeCRjTSeM16Kaxa3smgAqgfaQ
Message-Id: <20051221121050.ABC559DC804@postgresql.org>


>Why not just query adjacent databases, rather than copying the data =
around?

The reasons I didn't choose this way were:
1) I didn't think there's a way to write a query that can act on the =
data in
two
Databases as though it was all in one, and I didn't want to get into =
merging
multiple database query results on the Application side. I'd rather just
have all the needed data sitting in a single database so that I can =
perform
whatever query I like without complication.
2) Most database accesses are reads, and I didn't want a big network
overhead for these, especially since I'm aiming for each database to be
entirely RAM resident.

>If you really wanted to do this, do you need 2pc?=A0 Once data has been
uploaded to the database for region A, then asynchronously copy the data =
to
B, C, D and E later, using a queue.=A0=20

I've always assumed that my data needed to be consistent. I guess there =
are
some circumstances where it isn't really a problem, but each would need =
to
be carefully evaluated. The easy answer is to say 'yes, it must be
consistent'.

>If you try to commit to all at once, then if one fails, then none has =
the
data.

Yes, I'd prefer things to be that way in any event.

Regards,
Andy