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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
