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

From Thomas Munro
Subject Re: Use fadvise in wal replay
Date
Msg-id CA+hUKG+Wr6JSpPibxVME8ksRUTNFrsnjOBrc3U6uyhzs-DePRw@mail.gmail.com
Whole thread Raw
In response to RE: Use fadvise in wal replay  (Jakub Wartak <Jakub.Wartak@tomtom.com>)
Responses Re: Use fadvise in wal replay
RE: Use fadvise in wal replay
List pgsql-hackers
On Tue, Jun 21, 2022 at 10:33 PM Jakub Wartak <Jakub.Wartak@tomtom.com> wrote:
> > > Maybe the important question is why would be readahead mechanism be
> > disabled in the first place via /sys | blockdev ?
> >
> > Because database should know better than OS which data needs to be
> > prefetched and which should not. Big OS readahead affects index scan
> > performance.
>
> OK fair point, however the patch here is adding 1 syscall per XLOG_BLCKSZ which is not cheap either. The code is
alreadyhot and there is example from the past where syscalls were limiting the performance [1]. Maybe it could be
prefetchingin larger batches (128kB? 1MB? 16MB?)  ? 

I've always thought we'd want to tell it about the *next* segment
file, to smooth the transition from one file to the next, something
like the attached (not tested).

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: gcc -ftabstop option
Next
From: Thomas Munro
Date:
Subject: Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?