Re: crash-safe visibility map, take three
От | Bruce Momjian |
---|---|
Тема | Re: crash-safe visibility map, take three |
Дата | |
Msg-id | 201012010135.oB11Zud04761@momjian.us обсуждение исходный текст |
Ответ на | Re: crash-safe visibility map, take three (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: crash-safe visibility map, take three
|
Список | pgsql-hackers |
Heikki Linnakangas wrote: > On 30.11.2010 18:33, Tom Lane wrote: > > Robert Haas<robertmhaas@gmail.com> writes: > >> Oh, but it's worse than that. When you XLOG a WAL record for each of > >> those pages, you're going to trigger full-page writes for all of them. > >> So now you've turned 1GB of data to write into 2+ GB of data to > >> write. > > > > No, because only the first mod of each VM page would trigger a full page > > write, at least assuming a reasonable ordering of the operations. > > If you change the LSN on the heap pages, you have to write full page > images of those as well. > > Let's recap what happens when a VM bit is set: You set the > PD_ALL_VISIBLE flag on the heap page (assuming it's not set already, it > usually isn't), and then set the bit in the VM while keeping the heap > page locked. What if we set PD_ALL_VISIBLE on the heap page, wait for a checkpoint to happen so the heap page is guaranteed to be on disk, then on next read, if PD_ALL_VISIBLE is set and the VM all-visible bit is not set, set the VM bit. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: