Re: Avoiding unnecessary reads in recovery - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Avoiding unnecessary reads in recovery
Date
Msg-id 1177514181.20637.137.camel@silverbirch.site
Whole thread Raw
In response to Avoiding unnecessary reads in recovery  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Avoiding unnecessary reads in recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2007-04-25 at 13:48 +0100, Heikki Linnakangas wrote:

> I was surprised how big a difference it makes, but when you think about 
> it it's logical. Without the patch, it's doing roughly the same I/O as 
> the test itself, reading in pages, modifying them, and writing them 
> back. With the patch, all the reads are done sequentially from the WAL, 
> and then written back in a batch at the end of the WAL replay which is a 
> lot more efficient.

Interesting patch.

It would be good to see a longer term test. I'd expect things to fall
back to about 50% of the time on a longer recovery where the writes need
to be written out of cache.

I was thinking of getting the bgwriter to help out to improve matters
there.


Patch-wise, I love the name ZapBuffer() but would think that
OverwriteBuffer() would be more descriptive.

As regards the zero_damaged_pages question, I raised that some time ago
but we didn't arrive at an explicit answer. All I would say is we can't
allow invalid pages in the buffer manager at any time, whatever options
we have requested, otherwise other code will fail almost immediately.
I'm not sure there's another option?

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: ECPG failure on BF member Vaquita (Windows Vista)
Next
From: Neil Conway
Date:
Subject: Re: temporal variants of generate_series()