X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 3169B9DCA5B
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue, 20 Dec 2005 11:00:37 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 93099-10
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue, 20 Dec 2005 11:00:40 -0400 (AST)
X-Greylist: delayed 01:34:32.186547 by SQLgrey-
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com
	[66.111.4.28]) by postgresql.org (Postfix) with ESMTP id 6CD0D9DCA55
	for <pgsql-performance@postgresql.org>;
	Tue, 20 Dec 2005 11:00:33 -0400 (AST)
Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149])
	by frontend1.messagingengine.com (Postfix) with ESMTP id 328BDD24972;
	Tue, 20 Dec 2005 10:00:36 -0500 (EST)
Received: from frontend2.messagingengine.com ([10.202.2.151])
	by frontend1.internal (MEProxy); Tue, 20 Dec 2005 10:00:36 -0500
X-Sasl-enc: WmzwR+sU3FEm+epDz/88uIEkxTUKfKEhy7rhznKmBdnt 1135090835
Received: from [149.182.235.91] (unknown [129.230.248.1])
	by frontend2.messagingengine.com (Postfix) with ESMTP id 34DAE5714A4;
	Tue, 20 Dec 2005 10:00:30 -0500 (EST)
Message-ID: <43A81C8E.6010602@diroussel.xsmail.com>
Date: Tue, 20 Dec 2005 15:00:30 +0000
From: David Roussel <pgsql-performance@diroussel.xsmail.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: andy@areyoulocal.co.uk
CC: pgsql-performance@postgresql.org
Subject: Re: 2 phase commit: performance implications?
References: <ECOWS02MiFq70r4q6bs00009e82@smtp-out2.blueyonder.co.uk>
In-Reply-To: <ECOWS02MiFq70r4q6bs00009e82@smtp-out2.blueyonder.co.uk>
Content-Type: multipart/alternative;
	boundary="------------010008000500000505060002"
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.121 required=5 tests=[AWL=0.120,
 HTML_MESSAGE=0.001]
X-Spam-Score: 0.121
X-Spam-Level: 
X-Archive-Number: 200512/490
X-Sequence-Number: 16311

This is a multi-part message in MIME format.
--------------010008000500000505060002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>The only issue is to ensure that a query near a boundary between two
>adjacent areas behaves as though there was no partitioning. To do this, I'm
>looking into using  8.1's new 2PC to allow me to selectively copy data
>inserted near a boundary into the adjacent neighbouring databases, so that
>this data will appear in boundary searches carried out by the neighbours.
>
Why not just query adjacent databases, rather than copying the data around?

If you really wanted to do this, do you need 2pc?  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.  If you try to commit to all at 
once, then if one fails, then none has the data.

All depends on what type of data you are dealing with, how important is 
consistency, i.e. will it cost you money if the data is inconsistent 
between nodes.

Generally queuing is your friend.  You can use 2pc to ensure your queues 
work correctly if you like.

David

--------------010008000500000505060002
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#333333">
<br>
<blockquote
 cite="midECOWS02MiFq70r4q6bs00009e82@smtp-out2.blueyonder.co.uk"
 type="cite">
  <pre wrap="">
The only issue is to ensure that a query near a boundary between two
adjacent areas behaves as though there was no partitioning. To do this, I'm
looking into using  8.1's new 2PC to allow me to selectively copy data
inserted near a boundary into the adjacent neighbouring databases, so that
this data will appear in boundary searches carried out by the neighbours.</pre>
</blockquote>
Why not just query adjacent databases, rather than copying the data
around?<br>
<br>
If you really wanted to do this, do you need 2pc?&nbsp; 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.&nbsp; If you try to commit to
all at once, then if one fails, then none has the data.<br>
<br>
All depends on what type of data you are dealing with, how important is
consistency, i.e. will it cost you money if the data is inconsistent
between nodes.<br>
<br>
Generally queuing is your friend.&nbsp; You can use 2pc to ensure your
queues work correctly if you like.<br>
<br>
David<br>
</body>
</html>

--------------010008000500000505060002--