Re: [WIP] Performance Improvement by reducing WAL for Update Operation

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Дата
Msg-id 001801cd760b$e6b6f440$b424dcc0$@kapila@huawei.com
обсуждение исходный текст
Ответ на Re: [WIP] Performance Improvement by reducing WAL for Update Operation  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
From: Simon Riggs [mailto:simon@2ndQuadrant.com] 
Sent: Thursday, August 09, 2012 12:36 PM
On 3 August 2012 12:46, Amit kapila <amit.kapila@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,
Howeverfor 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
implementationit 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
above2
 
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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [WIP] Performance Improvement by reducing WAL for Update Operation