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

From Florian Weimer
Subject Re: Read-ahead and parallelism in redo recovery
Date
Msg-id 82ablj4zw1.fsf@mid.bfk.de
Whole thread Raw
In response to Read-ahead and parallelism in redo recovery  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Responses Re: Read-ahead and parallelism in redo recovery  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
* Pavan Deolasee:

> The current redo-recovery is a single threaded, synchronous process.
> The XLOG is read sequentially, each log record is examined and
> replayed if required. This requires reading disk blocks in the
> shared buffers and applying changes to the buffer. The reading
> happens synchronously and that would usually make the redo process
> very slow.

Are you sure that it's actually slow for that reason?  Sequential I/O
on the log is typically quite fast, and if the pages dirtied since the
last checkpoint fit into the cache (shared buffers or OS cache), even
that part of recovery does not result in lots of random I/O (with 8.3
and full page writes active; this is a relatively recent change).

In the end, I wouldn't be surprised if for most loads, cache warming
effects dominated recovery times, at least when the machine is not
starved on RAM.

--
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Why we panic in pglz_decompress
Next
From: "Florian G. Pflug"
Date:
Subject: Re: Read-ahead and parallelism in redo recovery