Re: Use fadvise in wal replay
От | Andrey Borodin |
---|---|
Тема | Re: Use fadvise in wal replay |
Дата | |
Msg-id | 7D2D4F31-5B9D-4BCF-9F33-E2CA164E936A@yandex-team.ru обсуждение исходный текст |
Ответ на | RE: Use fadvise in wal replay (Jakub Wartak <Jakub.Wartak@tomtom.com>) |
Ответы |
RE: Use fadvise in wal replay
|
Список | pgsql-hackers |
> 23 июня 2022 г., в 13:50, Jakub Wartak <Jakub.Wartak@tomtom.com> написал(а): > > Thoughts? The patch leaves 1st 128KB chunk unprefetched. Does it worth to add and extra branch for 120KB after 1st block when readOff==0? Or maybe do + posix_fadvise(readFile, readOff + XLOG_BLCKSZ, RACHUNK, POSIX_FADV_WILLNEED); instead of + posix_fadvise(readFile, readOff + RACHUNK , RACHUNK, POSIX_FADV_WILLNEED); ? > Notes: > - no GUC, as the default/identical value seems to be the best I think adding this performance boost on most systems definitely worth 1 syscall per 16 pages. And I believe 128KB to beoptimal for most storages. And having no GUCs sounds great. But storage systems might be different, far beyond benchmarks. All in all, I don't have strong opinion on having 1 or 0 GUCs to configure this. I've added patch to the CF. Thanks! Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: