On Tue, Nov 30, 2010 at 11:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
