Re: WAL prefetch

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: WAL prefetch
Дата
Msg-id 20180709182848.jirhtmuvcochkrk5@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: WAL prefetch  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: WAL prefetch  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers
Hi,

On 2018-07-09 11:59:06 +0200, Tomas Vondra wrote:
> > * During the design phase, I looked into using bgworkers but given the number of
> >    in-flight pread(2) calls required to fully utilize the IO subsystem, I opted
> >    for something threaded (I was also confined to using Solaris which doesn't
> >    support posix_fadvise(2), so I couldn't sequentially dispatch async
> >    posix_fadvise(2) calls and hope for the best).
> > 
> 
> Hmm, yeah. I'm not sure what to do with this. Using many (thousands?) of
> prefetch processes seems like a bad idea - we surely can't make them regular
> bgworkers. Perhaps we could use one process with many threads?

> Presumably if we knew about a better way to do prefetching without
> posix_fadvise, we'd have implemented it in FilePrefetch(). But we just error
> out instead :-(

Solaris is dead. We shouldn't design for it... I think there's decent
reasons to go for a non fadvise approach, but solaris imo isn't one of
them.

Greetings,

Andres Freund


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: How can we submit code patches that implement our (pending)patents?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Proposed fix for Bug #15259 (invalid empty array returned by intarray "&" operator)