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

From Jakub Wartak
Subject RE: Use fadvise in wal replay
Date
Msg-id AM8PR07MB8248B4D3742BCB79B34C7F5AF6B59@AM8PR07MB8248.eurprd07.prod.outlook.com
Whole thread Raw
In response to Re: Use fadvise in wal replay  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: Use fadvise in wal replay
Re: Use fadvise in wal replay
List pgsql-hackers
>> > On 21 Jun 2022, at 16:59, Jakub Wartak <jakub.wartak@tomtom.com> wrote:
>> Oh, wow, your benchmarks show really impressive improvement.
>>
>> > I think that 1 additional syscall is not going to be cheap just for
>> > non-standard OS configurations
>> Also we can reduce number of syscalls by something like
>>
>> #if defined(USE_POSIX_FADVISE) && defined(POSIX_FADV_WILLNEED)
>>     if ((readOff % (8 * XLOG_BLCKSZ)) == 0)
>>         posix_fadvise(readFile, readOff + XLOG_BLCKSZ, XLOG_BLCKSZ * 8,
>> POSIX_FADV_WILLNEED); #endif
>>
>> and maybe define\reuse the some GUC to control number of prefetched pages
>> at once.

Hi, I was thinking the same, so I got the patch (attached) to the point it gets the identical performance with and
withoutreadahead enabled: 

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

Thoughts?

Notes:
- no GUC, as the default/identical value seems to be the best
- POSIX_FADV_SEQUENTIAL is apparently much slower and doesn't seem to have effect from xlogreader.c at all while
_WILLNEEDdoes (testing again contradicts "common wisdom"?) 

-J.

Attachment

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Custom tuplesorts for extensions
Next
From: Andrey Borodin
Date:
Subject: Re: Use fadvise in wal replay