Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>, Thomas Munro <thomas.munro@enterprisedb.com>, Tobias Oberstein <tobias.oberstein@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-04-25T20:33:33Z
Lists: 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

Commits

  1. Use pg_pread() and pg_pwrite() for data files and WAL.

  2. Perform less setup work for AFTER triggers at transaction start.