From: Simon Riggs [mailto:si...@2ndquadrant.com]
Sent: Thursday, August 09, 2012 12:36 PM
On 3 August 2012 12:46, Amit kapila <amit.kap...@huawei.com> wrote:
>> Frame the new tuple from old tuple and WAL record:
> Sounds good.
Thanks.
> 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?
> 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.
> Personally, I think it will be important to ensure the above,
> otherwise recovery will require much additional code for that case.
In recovery currently also, it handles the case when old and new are on
different page such that
it has to read old page to get the old tuple.
The modifications needs to ensure handling of following cases:
a. When there is backup block,and old-new tuples are on different page
Currently it doesn't read the old page,
However for new implementation it needs to read old page for this case
also.
b. When changes are already applied on page [line : if (XLByteLE(lsn,
PageGetLSN(page))); function: heap_xlog_update]
Currently it doesn't read the old page,
However for new implementation it needs to read old page for this case
also.
> And that code will be prone to race conditions and performance issues.
Are you telling performance issues, as now we may need to read old page in
some of the cases
when earlier it was not reading?
If yes, then I think as I have mentioned above, according to me above 2
cases are not very usual cases.
However the benefit of Update operation on running server is good enough
as it reduces the WAL volume.
If other then above, then please suggest me.
> 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.
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
