Re: Read-ahead and parallelism in redo recovery

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Read-ahead and parallelism in redo recovery
Дата
Msg-id 2e78013d0803022246j2a1ef2a9l4d5469983b2b8790@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Read-ahead and parallelism in redo recovery  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: Read-ahead and parallelism in redo recovery
Следующее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables