From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Oskari Saarenmaa <os@ohmu.fi>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Use pread and pwrite instead of lseek + write and read
Date: Wed, 17 Aug 2016 15:11:15 -0400
Message-ID: <6352.1471461075@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmobEq_C2t=bqBCQnwwgfXDMbbVdfndpkfyY4vCtZFveQ2A@mail.gmail.com>
References: <a86bd200-ebbe-d829-e3ca-0c4474b2fcb7@ohmu.fi>
<7109.1471441241@sss.pgh.pa.us>
<CA+TgmobEq_C2t=bqBCQnwwgfXDMbbVdfndpkfyY4vCtZFveQ2A@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Robert Haas <robertmhaas@gmail.com> writes:
> I don't understand why you think this would create non-trivial
> portability issues.
The patch as submitted breaks entirely on platforms without pread/pwrite.
Yes, we can add a configure test and some shim functions to fix that,
but the argument that it makes the code shorter will get a lot weaker
once we do.
I agree that adding such functions is pretty trivial, but there are
reasons to think there are other hazards that are less trivial:
First, a self-contained shim function will necessarily do an lseek every
time, which means performance will get *worse* not better on non-pread
platforms. And yes, the existing logic to avoid lseeks fires often enough
to be worthwhile, particularly in seqscans.
Second, I wonder whether this will break any kernel's readahead detection.
I wouldn't be too surprised if successive reads (not preads) without
intervening lseeks are needed to trigger readahead on at least some
platforms. So there's a potential, both on platforms with pread and those
without, for this to completely destroy seqscan performance, with
penalties very far exceeding what we might save by avoiding some kernel
calls.
I'd be more excited about this if the claimed improvement were more than
1.5%, but you know as well as I do that that's barely above the noise
floor for most performance measurements. I'm left wondering why bother,
and why take any risk of de-optimizing on some platforms.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, os@ohmu.fi
Subject: Re: Use pread and pwrite instead of lseek + write and read
In-Reply-To: <6352.1471461075@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox