Re: Use fadvise in wal replay - Mailing list pgsql-hackers

From Pavel Borisov
Subject Re: Use fadvise in wal replay
Date
Msg-id CALT9ZEF+cTE1O6yAtUmopatH7XbHApOH1AfaWM1GWLV-d0sn+w@mail.gmail.com
Whole thread Raw
In response to Re: Use fadvise in wal replay  (Pavel Borisov <pashkin.elfe@gmail.com>)
List pgsql-hackers
On Sat, 26 Nov 2022 at 01:10, Pavel Borisov <pashkin.elfe@gmail.com> wrote:
>
> Hi, hackers!
>
> On Sun, 13 Nov 2022 at 02:02, Andrey Borodin <amborodin86@gmail.com> wrote:
> >
> > On Sun, Aug 7, 2022 at 9:41 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> > >
> >
> > Hi everyone. The patch is 16 lines, looks harmless and with proven
> > benefits. I'm moving this into RfC.
>
> As I've written up in the thread we can not gain much from this
> optimization. The results of Jakub shows around 2% difference:
>
> >baseline, master, default Linux readahead (128kb):
> >33.979, 0.478
> >35.137, 0.504
> >34.649, 0.518>
>
> >master+patched, readahead disabled:
> >34.338, 0.528
> >34.568, 0.575
> >34.007, 1.136
>
> >master+patched, readahead enabled (as default):
> >33.935, 0.523
> >34.109, 0.501
> >33.408, 0.557
>
> On the other hand, the patch indeed is tiny and I don't think the
> proposed advise can ever make things bad. So, I've looked through the
> patch again and I agree it can be committed in the current state.

My mailer corrected my previous message. The right one is:
"On the other hand, the patch indeed is tiny and I don't think the
proposed _fadvise_ can ever make things bad".

Pavel.



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Small miscellaneus fixes (Part II)
Next
From: Cary Huang
Date:
Subject: Re: [PATCH] Simple code cleanup in tuplesort.c.