RE: Use fadvise in wal replay - Mailing list pgsql-hackers

From Jakub Wartak
Subject RE: Use fadvise in wal replay
Date
Msg-id AM8PR07MB8248A3209904758AAD49731AF6B59@AM8PR07MB8248.eurprd07.prod.outlook.com
Whole thread Raw
In response to Re: Use fadvise in wal replay  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: Use fadvise in wal replay  (Robert Haas <robertmhaas@gmail.com>)
Re: Use fadvise in wal replay  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
Hey Andrey,

> > 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 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.

Cool. As for GUC I'm afraid there's going to be resistance of adding yet another GUC (to avoid many knobs). Ideally it
wouldbe nice if we had some advanced/deep/hidden parameters , but there isn't such thing.
 
Maybe another option would be to use (N * maintenance_io_concurrency * XLOG_BLCKSZ), so N=1 that's 80kB and N=2 160kB
(prettyclose to default value, and still can be tweaked by enduser). Let's wait what others say?
 

-J.

pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Use fadvise in wal replay
Next
From: Alexander Korotkov
Date:
Subject: Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64