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
Re: Use fadvise in wal replay |
Список | 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 по дате отправления: