On 9 August 2012 09:49, Amit Kapila <amit.kap...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
