Re: Replication on the backend

From: Gregory Maxwell <gmaxwell(at)gmail(dot)com>
To: Jan Wieck <JanWieck(at)yahoo(dot)com>
Cc: Mario Weilguni <mario(dot)weilguni(at)icomedias(dot)com>, Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Replication on the backend
Date: 2005-12-07 05:09:03
Message-ID: e692861c0512062109s265530dene52ba49226e7b613@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/6/05, Jan Wieck <JanWieck(at)yahoo(dot)com> wrote:
> > IMO this is not true. You can get affordable 10GBit network adapters, so you can have plenty of bandwith in a db server pool (if they are located in the same area). Even 1GBit Ethernet greatly helps here, and would make it possible to balance read-intensive (and not write intensive) applications. We using linux bonding interface with 2 gbit NICs, and 200 MBytes/sec throughput is something you need to have a quite some harddisks to reach that. Latency is not bad too.
>
> It's not so much the bandwidth but more the roundtrips that limit your
> maximum transaction throughput. Remember, whatever the priority, you
> can't increase the speed of light.

Eh, why would light limited delay be any slower than a disk on FC the
same distance away? :)

In any case, performance of PG on iscsi is just fine. You can't blame
the network... Doing multimaster replication is hard because the
locking primitives that are fine on a simple multiprocessor system
(with a VERY high bandwidth very low latency interconnect between
processors) just don't work across a network, so you're left finding
other methods and making them work...

But again, multimaster isn't hard because there of some inherently
slow property of networks.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Kirkwood 2005-12-07 05:39:02 Re: row is too big: size 8916, maximum size 8136
Previous Message Tom Lane 2005-12-07 05:06:23 Re: [GENERAL] 8.1, OID's and plpgsql