RE: Use fadvise in wal replay

Поиск
Список
Период
Сортировка
От Jakub Wartak
Тема RE: Use fadvise in wal replay
Дата
Msg-id AM8PR07MB8248B4D3742BCB79B34C7F5AF6B59@AM8PR07MB8248.eurprd07.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Use fadvise in wal replay  (Andrey Borodin <x4mmm@yandex-team.ru>)
Ответы Re: Use fadvise in wal replay  (Andrey Borodin <x4mmm@yandex-team.ru>)
Re: Use fadvise in wal replay  (Andrey Borodin <x4mmm@yandex-team.ru>)
Список 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.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Custom tuplesorts for extensions
Следующее
От: Andrey Borodin
Дата:
Сообщение: Re: Use fadvise in wal replay