On Thu, 2010-01-28 at 13:05 -0500, Tom Lane wrote:
> > I'm a little worried the feature set of streaming rep isn't any better
> > than what we have already.
>
> Nonsense. Getting rid of the WAL-segment-based shipping delays is a
> quantum improvement --- it means we actually have something approaching
> real-time replication, which was really impractical before.
SR does not give us anything like replication. Replication implies an
ability to read from the Slave. That is HS only territory.
>From what I read on the wiki SR doesn't give us anything that PostgreSQL
+ PITRTools doesn't already give us. And PITR Tools works as far back as
8.1 (although I would suggest 8.2+).
One thing I am unclear on, is if with SR the entire log must be written
before it streams to the slaves. If the entire log does not need to be
written, then that is one up on PITRTools in that we have to wait for
archive_command to execute.
> (Anyway, the argument that it's important for performance is pure
> speculation AFAIK, untainted by any actual measurements. Given the lack
> of optimization of WAL replay, it seems entirely possible that the last
> thing you want to burden a slave with is sourcing data to more slaves.)
>
I agree. WAL replay as a whole is a bottlekneck. As it stands now (I
don't know about 8.5), replay is a large bottleneck on keeping the
warm-standby up to date.
Sincerely,
Joshua D. Drake
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.