Re: WAL prefetch

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Sean Chittenden <seanc(at)joyent(dot)com>
Subject: Re: WAL prefetch
Date: 2018-06-16 05:12:35
Message-ID: f135d035-8272-4df3-b36d-bb88a8dea159@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16.06.2018 06:30, Amit Kapila wrote:
> On Fri, Jun 15, 2018 at 8:45 PM, Konstantin Knizhnik
> <k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
>> On 15.06.2018 18:03, Amit Kapila wrote:
>>
>> wal_prefetch is prefetching blocks referenced by WAL records. But in case of
>> "full page writes" such prefetch is not needed and even is harmful.
>>
> Okay, IIUC, the basic idea is to prefetch recently modified data
> pages, so that they can be referenced. If so, isn't there some
> overlap with autoprewarm functionality which dumps recently modified
> blocks and then on recovery, it can prefetch those?
>
Sorry,  I do not see any intersection with autoprewarw functionality:
wal prefetch is performed at replica where data was not yet modified:
actually the goal of WAL prefetch is to make this update more efficient.
WAL prefetch can be also done at standalone server to speed up recovery
after crash. But it seems to be much more exotic use case.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2018-06-16 05:14:06 Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"
Previous Message Robert Haas 2018-06-16 04:13:35 Re: [HACKERS] Statement-level rollback