Re: Use fadvise in wal replay

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.

In response to

Responses

Browse pgsql-hackers by date

  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