Re: Replication on the backend - Mailing list pgsql-hackers

From Gregory Maxwell
Subject Re: Replication on the backend
Date
Msg-id e692861c0512062109s265530dene52ba49226e7b613@mail.gmail.com
Whole thread Raw
In response to Re: Replication on the backend  (Jan Wieck <JanWieck@Yahoo.com>)
Responses Re: Replication on the backend
List pgsql-hackers
On 12/6/05, Jan Wieck <JanWieck@yahoo.com> wrote:
> > IMO this is not true. You can get affordable 10GBit network adapters, so you can have plenty of bandwith in a db
serverpool (if they are located in the same area). Even 1GBit Ethernet greatly helps here, and would make it possible
tobalance read-intensive (and not write intensive) applications. We using linux bonding interface with 2 gbit NICs, and
200MBytes/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.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] 8.1, OID's and plpgsql
Next
From: Mark Kirkwood
Date:
Subject: Re: row is too big: size 8916, maximum size 8136