Re: Use fadvise in wal replay

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Kirill Reshke <reshke(at)double(dot)cloud>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Use fadvise in wal replay
Date: 2022-08-06 05:23:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi Bharath,

thank you for the suggestion.

> On 5 Aug 2022, at 16:02, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> On Thu, Aug 4, 2022 at 9:48 PM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>>> On 18 Jul 2022, at 22:55, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Thu, Jun 23, 2022 at 5:49 AM Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com> wrote:
> I have a fundamental question on the overall idea - How beneficial it
> will be if the process that's reading the current WAL page only does
> (at least attempts) the prefetching of future WAL pages? Won't the
> benefit be higher if "some" other background process does prefetching?

IMO prefetching from other thread would have negative effect.
fadvise() call is non-blocking, startup process won't do IO. It just informs kernel to schedule asynchronous page read.
On the other hand synchronization with other process might cost more than fadvise().

Anyway cost of calling fadise() once per 16 page reads is neglectable.

Thank you!

Best regards, Andrey Borodin.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-08-06 06:26:12 Re: [PATCH] Expose port->authn_id to extensions and triggers
Previous Message Andres Freund 2022-08-06 03:53:44 Re: [RFC] building postgres with meson -v