On Tuesday, July 23, 2013 7:06 PM Andres Freund wrote: > 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... I think once a record is corrupted on page, user has to reconstruct that page, it might be difficult to just reconstruct a record and this optimization will not carry forward any corruption from one to another Page. > > > * 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.
With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers