On 2013-07-23 18:59:11 +0530, Amit Kapila wrote: > > * I'd be very surprised if this doesn't make WAL replay of update heavy > > workloads slower by at least factor of 2. > > Yes, if you just consider the cost of replay, but it involves other > operations as well > like for standby case transfer of WAL, Write of WAL, Read from WAL and > then apply. > So among them most operation's will be benefited from reduced WAL size, > except apply where you need to decode.
I still think it's rather unlikely that they offset those. I've seen wal replay be a major bottleneck more than once... > > * It makes data recovery from WAL *noticeably* harder since data > > corruption now is carried forwards and you need the old data to > > decode > > new data > > This is one of the reasons why this optimization is done only when the > new row goes in same page. That doesn't help all that much. It somewhat eases recovering data if full_page_writes are on, but it's realy hard to stitch together all changes if the corruption occured within a 1h long checkpoint... > > * It makes changeset extraction either more expensive or it would have > > to be disabled there. > I think, if there is any such implication, we can probably have the > option of disable it That can just be done on wal_level = logical, that's not the problem. It's certainly not with precedence that we have wal_level dependent optimizations. > > I think my primary issue is that philosophically/architecturally I am > > of > > the opinion that a wal record should make sense of it's own without > > depending on heap data. And this patch looses that. > > Is the main worry about corruption getting propagated? Not really. It "feels" wrong to me architecturally. That's subjective, I know. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers