Re: WAL prefetch

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Sean Chittenden <seanc(at)joyent(dot)com>
Subject: Re: WAL prefetch
Date: 2018-06-16 20:31:49
Message-ID: 40408869-067e-d1cf-3fef-4f380a2e5d38@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16.06.2018 22:23, Andres Freund wrote:
> Hi,
>
> On 2018-06-13 16:09:45 +0300, Konstantin Knizhnik wrote:
>> Usage:
>> 1. At master: create extension wal_prefetch
>> 2. At replica: Call pg_wal_prefetch() function: it will not return until you
>> interrupt it.
> FWIW, I think the proper design would rather be a background worker that
> does this work. Forcing the user to somehow coordinate starting a
> permanently running script whenever the database restarts isn't
> great. There's also some issues around snapshots preventing vacuum
> (which could be solved, but not nicely).

As I already wrote, the current my approach with extension and
pg_wal_prefetch function called by user can be treated only as prototype
implementation which can be used to estimate efficiency of prefetch. But
in case of prefetching in shared buffers, one background worker will not
be enough. Prefetch can can speedup recovery process if it performs
reads in parallel or background. So more than once background worker
will be needed for prefetch if we read data to Postgres shared buffers
rather then using posix_prefetch to load page in OS cache.

>
> Greetings,
>
> Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-06-17 00:00:14 Re: WAL prefetch
Previous Message Konstantin Knizhnik 2018-06-16 20:25:34 Re: WAL prefetch