Re: [Postgres-xc-general] Node redundancy

[Koichi S. <koi...@gm...>]

We can reduce the additional latency by performing prepare and commit
in parallel, I mean, sending command to all the target remote nodes
first and then receive their response afterwords.

As I supposed, alternative is to use BDR.   This has very small
overhead.   We can detect conflicting writes among transactions and if
each transaction does not conflict, we can apply these writes in
parallel, not in a single thread as we're doing in streaming
replication.

This needs some more work and I think this worth to spend some time.

Regards;
---
Koichi Suzuki


2014-05-28 9:50 GMT+09:00 Michael Paquier <mic...@gm...>:
> On Wed, May 28, 2014 at 8:42 AM, Josh Berkus <jo...@ag...> wrote:
>> On 05/26/2014 05:10 PM, Tim Uckun wrote:
>>> Would it be possible to keep the shards in multiple data nodes so that if
>>> one data node failed you'd just replace it when you can get around to it.
>>
>> Right, that's what I was describing.  It's the standard way to deal with
>> redundancy in any parallel sharded database.
>>
>> The drawback is that it increases write times, because you can't count a
>> write as saved unless all shards return.  This is why some databases
>> (e.g. Cassandra) go one step further and have, say, each shard in 3
>> places and only 2 need to return.  That gets way complicated though.
> That's an additional overhead for 2PC as you need to wait for all the
> nodes where a write occurred to have executed PREPARE. This also drops
> any hopes to have autocommit write transactions, sinking performance
> down particularly for OLTP apps, smth that XC plays well with by
> design.
> --
> Michael