Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..
Дата
Msg-id 20180425203333.iga6brlp2yhzuhae@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On 2018-04-25 14:41:44 -0400, Robert Haas wrote:
> On Mon, Apr 16, 2018 at 2:13 AM, Andrew Gierth
> <andrew@tao11.riddles.org.uk> wrote:
> > The code that detects sequential behavior can not distinguish between
> > pread() and lseek+read, it looks only at the actual offset of the
> > current request compared to the previous one for the same fp.
> >
> >  Thomas> +1 for adopting pread()/pwrite() in PG12.
> >
> > ditto
> 
> Likewise.

+1 as well. Medium term I forsee usage of at least pwritev(), and
possibly also preadv(). Being able to write out multiple buffers at once
is pretty crucial if we ever want to do direct IO.

Greetings,

Andres Freund


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: WIP: a way forward on bootstrap data
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: a way forward on bootstrap data