Re: [WIP] Performance Improvement by reducing WAL for Update Operation
От | Simon Riggs |
---|---|
Тема | Re: [WIP] Performance Improvement by reducing WAL for Update Operation |
Дата | |
Msg-id | CA+U5nML=3CoCdrjwMZYuDC2sbFmO03fxpdHrrCgEdnBdB4=kDQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [WIP] Performance Improvement by reducing WAL for Update Operation (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: [WIP] Performance Improvement by reducing WAL for Update
Operation
|
Список | pgsql-hackers |
On 9 August 2012 11:30, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > On 09.08.2012 12:18, Simon Riggs wrote: >> >> On 9 August 2012 09:49, Amit Kapila<amit.kapila@huawei.com> wrote: >> >>> 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. > > > That was my first instinctive reaction too. But if the mechanism works just > as well for cross-page updates, seems a bit strange to not use it. > > One argument would be that if for some reason the old block is corrupt or > lost, you would not be able to recover the new version of the tuple from the > WAL alone. At the moment, it's nice that the WAL record contains all the > information required to reconstruct the new tuple, regardless of the old > data block contents. Exactly. If we lose the first block in a checkpoint, we could lose all updates to rows in that page and all other pages linked to it over a whole checkpoint duration. Basically, page corruption will propogate from block to block if we do this. Given the marginal gain because of a low percentage of cross-block updates, I'm not keen. Low percentage because HOT tries hard to keep things on same block - even for non-HOT updates (which is the case, even though it sounds weird). > But then again, full-page writes cover that too. There > will be a full-page image of the old block in the WAL anyway. Right, but we're planning to remove that, so its not a safe assumption to use when building new code. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: