From: David Roussel <pgsql-performance@diroussel.xsmail.com>
To: andy@areyoulocal.co.uk
Cc: pgsql-performance@postgresql.org
Subject: Re: 2 phase commit: performance implications?
Date: Tue, 20 Dec 2005 15:00:30 +0000
Message-ID: <43A81C8E.6010602@diroussel.xsmail.com> (raw)
In-Reply-To: <ECOWS02MiFq70r4q6bs00009e82@smtp-out2.blueyonder.co.uk>
References: <ECOWS02MiFq70r4q6bs00009e82@smtp-out2.blueyonder.co.uk>
>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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: pgsql-performance@diroussel.xsmail.com, andy@areyoulocal.co.uk
Subject: Re: 2 phase commit: performance implications?
In-Reply-To: <43A81C8E.6010602@diroussel.xsmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox