Re: Read-ahead and parallelism in redo recovery

I have added the following TODO:

* Speed WAL recovery by allowing more than one page to be prefetched

This involves having a separate process that can be told which pages
the recovery process will need in the near future.
http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php

---------------------------------------------------------------------------

Heikki Linnakangas wrote:
> Aidan Van Dyk wrote:
> > How difficult is it to parse the WAL logs with enough knowledge to know
> > what heap page (file/offset) a wal record contains (I haven't looked
> > into any wal code)?
>
> Unfortunately there's no common format for that. All the heap-related
> WAL records, insert, update and delete, have a
> RelFileNode+ItemPointerData at the beginning of the WAL payload, but
> update records have another ItemPointerData for the tid of the new tuple
> in addition to that. And all indexam WAL records use a format of their own.
>
> It would be nice to refactor that so that there was a common format to
> store the file+block number touched by WAL record. Like we have for full
> page images. That would useful for all kinds of external tools to parse
> WAL files, like the read-ahead restore_command you envisioned.
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your Subscription:
> http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +