Re: Use pread and pwrite instead of lseek + write and read - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: Use pread and pwrite instead of lseek + write and read
Date
Msg-id CAGTBQpZ2gVwFrCe=Fu_FNP0vrefndb6tqChPy2=MQHgMuDcbrQ@mail.gmail.com
Whole thread Raw
In response to Re: Use pread and pwrite instead of lseek + write and read  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Aug 17, 2016 at 10:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Oskari Saarenmaa <os@ohmu.fi> writes:
>> On my laptop a simple pgbench run (scale 100, 15 minutes) shows a 1.5%
>> performance improvement.
>
> I would have hoped for a lot better result before anyone would propose
> that we should deal with all the portability issues this'll create.
>
>> A 1.5% performance improvement is small but
>> measurable - and IMV more importantly it allows us to drop more than 100
>> lines of backwards (compatible?) code; maybe we could start targeting
>> more recent platforms in v10?
>
> That's basically nonsense: we'll end up adding way more than that to
> deal with platforms that haven't got these APIs.

Perhaps a better target would then be to try and make use of readv and
writev, which should both be useful for sequential access of various
kinds and network I/O. For instance, when reading 10 sequential
buffers, a readv could fill 10 buffers at a time.

I remember a project where we got a linear improvement in thoughput by
using them for network I/O, because we were limited by packet
thoughput rather than byte thoughput, and using the iovec utilities
reduced the overhead considerably.

But all this is anecdotal evidence in any case, YMMV.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: PATCH: Exclude additional directories in pg_basebackup
Next
From: Tom Lane
Date:
Subject: Re: Use pread and pwrite instead of lseek + write and read