Re: crash-safe visibility map, take three
От | Robert Haas |
---|---|
Тема | Re: crash-safe visibility map, take three |
Дата | |
Msg-id | AANLkTimD2ACTWWiCJowuoh9t5w79bxFVmnsvaqLxBdTi@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: crash-safe visibility map, take three (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Nov 30, 2010 at 11:33 AM, Tom Lane <tgl@sss.pgh.pa.us> 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. I'm not worried about the full-page writes from updating the visibility map - I'm worried about the full-page writes from updating the heap. It doesn't matter a whit if we fail to set a bit in the visibility map. What matters is if we DO set the bit in the visibility map but FAIL TO set the bit in the heap, because then a subsequent update to the heap page won't check the visibility map and clear the bit. The *heap* updates are the ones that have to be guaranteed to make it to disk. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: