From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Kirill Reshke <reshke(at)double(dot)cloud>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Use fadvise in wal replay |
Date: | 2022-06-23 09:30:45 |
Message-ID: | 7D2D4F31-5B9D-4BCF-9F33-E2CA164E936A@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 23 июня 2022 г., в 13:50, Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)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 be optimal 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jakub Wartak | 2022-06-23 09:49:31 | RE: Use fadvise in wal replay |
Previous Message | Jakub Wartak | 2022-06-23 08:50:51 | RE: Use fadvise in wal replay |