On Tue, Jun 7, 2011 at 4:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: >> On 07.06.2011 10:55, Simon Riggs wrote: >>> How would that help? > >> It doesn't matter whether the pages are zeroed while they sit in memory. >> And if you write a full page of WAL data, any wasted bytes at the end of >> the page don't matter, because they're ignored at replay anyway. The >> possibility of mistaking random garbage for valid WAL only occurs when >> we write a partial WAL page to disk. So, it is enough to zero the >> remainder of the partial WAL page (or just the next few words) when we >> write it out. > >> That's a lot cheaper than fully zeroing every page. (except for the fact >> that you'd need to hold WALInsertLock while you do it) > > I think avoiding the need to hold both locks at once is probably exactly > why the zeroing was done where it is. > > An interesting alternative is to have XLogInsert itself just plop down a > few more zeroes immediately after the record it's inserted, before it > releases WALInsertLock. This will be redundant work once the next > record gets added, but it's cheap enough to not matter IMO. As was > mentioned upthread, zeroing out the bytes that will eventually hold the > next record's xl_prev field ought to be enough to maintain a guarantee > that we won't believe the next record is valid.
Lets see what the overheads are with a continuous stream of short WAL records, say xl_heap_delete records. xl header is 32 bytes, xl_heap_delete is 24 bytes. So there would be ~145 records per page. 12 byte zeroing overhead per record gives 1740 total zero bytes written per page. The overhead is at worst case less than 25% of current overhead, plus its spread out across multiple records. When we get lots of full pages into WAL just after checkpoint we don't get as much overhead - nearly every full page forces a page switch. So we're removing overhead from where it hurts the most and amortising across other records. Maths work for me. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
