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.
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 |