Re: Replication on the backend

Поиск
Список
Период
Сортировка
От Gregory Maxwell
Тема Re: Replication on the backend
Дата
Msg-id e692861c0512062109s265530dene52ba49226e7b613@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Replication on the backend  (Jan Wieck <JanWieck@Yahoo.com>)
Ответы Re: Replication on the backend  ("J. Andrew Rogers" <jrogers@neopolitan.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] 8.1, OID's and plpgsql
Следующее
От: Mark Kirkwood
Дата:
Сообщение: Re: row is too big: size 8916, maximum size 8136