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.