Re: Read-ahead and parallelism in redo recovery - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Read-ahead and parallelism in redo recovery
Date
Msg-id 2e78013d0803022246j2a1ef2a9l4d5469983b2b8790@mail.gmail.com
Whole thread Raw
In response to Re: Read-ahead and parallelism in redo recovery  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-hackers
On Sat, Mar 1, 2008 at 2:13 AM, Heikki Linnakangas
<heikki@enterprisedb.com> wrote:
>
>
>  I used to think it's a big problem, but I believe the full-page-write
>  optimization in 8.3 made it much less so. Especially with the smoothed
>  checkpoints: as checkpoints have less impact on response times, you can
>  shorten checkpoint interval, which helps to keep the recovery time
>  reasonable.
>

I agree that smoothed checkpoints have considerably removed the response
time spikes we used to see in TPCC tests.

What I still don't like about the current checkpoint mechanism that it
writes all
the dirty buffers to disk. With very large shared buffers, this could
still be a problem.
Someday we may want to implement LAZY checkpoints which does not require
writing dirty pages and hence can be taken much more frequently. But lazy
checkpoints can increase the amount of redo  work to be done at the recovery
time. If we can significantly improve the recovery logic, we can then think of
reducing the work done at the checkpoint time (either through lazy checkpoints
or less frequent hard checkpoints) which would benefit the normal database
operation.


Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Re: Read-ahead and parallelism in redo recovery
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables