On 9 August 2012 09:49, Amit Kapila <amit.kapila@huawei.com> wrote:
>> I'd suggest we do this only when the saving is large enough for
>> benefit, rather than do this every time.
> Do you mean to say that when length of updated values of tuple is less
> than some threshold(1/3 or 2/3, etc..) value of
> total length?
Some heuristic, yes, similar to TOAST's minimum threshold. To attempt
removal of rows in all cases would not be worth it, so we need a fast
path way of saying lets just take all of the columns.
>> You don't mention whether or not the old and the new tuple are on the
>> same data block.
>
> WAL reduction is done for the case even when old and new are on different
> data blocks as well.
That makes me feel nervous. I doubt the marginal gain is worth it.
Most updates don't cross blocks.
>> Please also bear in mind that Andres will be looking to include the PK
>> columns in every WAL record for BDR. That could be an option, but I
>> doubt there is much value in excluding PK columns.
>
> Agreed. However once the implementation by Andres is done I can merge both
> codes and
> take the performance data again, based on which we can take decision.
It won't happen like that because there won't be a single point where
Andres is done. If you agree, then its worth doing it that way to
begin with, rather than requiring us to revisit the same section of
code twice.
One huge point that needs to be thought through is how we prove this
code actually works on WAL/recovery side. A normal regression test
won't prove that and we don't have a framework in place for that.
If you think about what you'll need to do to prove you haven't made
some fatal corruption of WAL, its going to look a lot like logical
replication tests. Worst case here is that mistakes on this patch will
show up as Andres' mistakes. So there is a stronger connection to
Andres' work than it first appears.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services