Re: Use fadvise in wal replay

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Use fadvise in wal replay
Дата
Msg-id CA+hUKG+Wr6JSpPibxVME8ksRUTNFrsnjOBrc3U6uyhzs-DePRw@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Use fadvise in wal replay  (Jakub Wartak <Jakub.Wartak@tomtom.com>)
Ответы Re: Use fadvise in wal replay  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
RE: Use fadvise in wal replay  (Jakub Wartak <Jakub.Wartak@tomtom.com>)
Список 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).

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: gcc -ftabstop option
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?