Simon Riggs <si...@2ndquadrant.com> writes:
> On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote:
>> Simon Riggs <si...@2ndquadrant.com> writes:
>>> The WAL is sent from master to standby in 8192 byte chunks, frequently
>>> including multiple commits. From standby, one reply per chunk. If we
>>> need to wait for apply while nothing else is received, we do.
>>
>> That premise is completely false. SR does not send WAL in page units.
>> If it did, it would have the same performance problems as the old
>> WAL-file-at-a-time implementation, just with slightly smaller
>> granularity.
> There's no dependence on pages in that proposal, so don't understand.
Oh, well you certainly didn't explain it well then.
What I *think* you're saying is that the slave doesn't send per-commit
messages, but instead processes the WAL as it's received and then sends
a heres-where-I-am status message back upstream immediately before going
to sleep waiting for the next chunk. That's fine as far as the protocol
goes, but I'm not convinced that it really does all that much in terms
of improving performance. You still have the problem that the master
has to fsync its WAL before it can send it to the slave. Also, the
slave won't know whether it ought to fsync its own WAL before replying.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
