Re: Core team statement on replication in PostgreSQL

* Marko Kreen <markokr(at)gmail(dot)com> [080529 12:27]:

> I don't think thats a problem. If the user runs its server at the
> limit of write-bandwidth, thats its problem.
>
> IOW, with synchronous replication, we _want_ the server to lag behind
> slaves.
>
> About the single-threading problem - afaik, the replay is mostly I/O bound
> so threading would not buy you much.

Right - the problem is that the master has N>1 backends working away,
preloading the modified heap pages into shared buffers, where they are
modified w/ WAL. This means the kernel/controller has man read-requests
in flight at a time as the modifies/writes chug along. The slave has to
read/modify/write every buffer, one at a time, as WAL arrives, meaning
there is ever only 1 IO request in flight at a time.

So the server as a queue of many parallel reads going on, the slave has
a set of sequential random reads going on.

a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.