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