Re: Use fadvise in wal replay

> On 18 Jul 2022, at 22:55, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Jun 23, 2022 at 5:49 AM Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com> wrote:
>> Cool. As for GUC I'm afraid there's going to be resistance of adding yet another GUC (to avoid many knobs). Ideally it would be 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 (pretty close to default value, and still can be tweaked by enduser). Let's wait what others say?
>
> I don't think adding more parameters is a problem intrinsically. A
> good question to ask, though, is how the user is supposed to know what
> value they should configure. If we don't have any idea what value is
> likely to be optimal, odds are users won't either.
We know that 128KB is optimal on some representative configuration and that changing value won't really affect performance much. 128KB is marginally better then 8KB and removes some theoretical concerns about extra syscalls.

> It's not very clear to me that we have any kind of agreement on what
> the basic approach should be here, though.

Actually, the only question is offset from current read position: should it be 1 block or full readehead chunk. Again, this does not change anything, just a matter of choice.

Thanks!

Best regards, Andrey Borodin.