Re: [PATCH] Using pread instead of lseek (with analysis) - Mailing list pgsql-patches

From Martijn van Oosterhout
Subject Re: [PATCH] Using pread instead of lseek (with analysis)
Date
Msg-id 20051010145209.GA29638@svana.org
Whole thread Raw
In response to Re: [PATCH] Using pread instead of lseek (with analysis)  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-patches
On Sun, Oct 09, 2005 at 12:19:57AM +0200, Martijn van Oosterhout wrote:
> > It would be reasonable to check results in fully-cached cases, which
> > would be the best real-world scenario for this to show any improvement
> > in.
>
> If you look, I did that and even then it simply didn't make a
> difference. lseek is 10 microseconds, you'd need to do hundreds of
> thousands of them to make a difference. And any gain would disappear in
> just the rotational latency of a hard disk read.

Just to clarify, I reexamined this point and there is a small
difference. The fully cached case went from 72 seconds to 70 over
890,000 (p)read syscalls, indicating that in that case lseek/read is
slower than pread by about 2 microseconds per call. The overall benefit
is about 2.5%.

This doesn't change the fact that any disk access at all renders the
benefit almost nil. On Linux anyway, other OSes, who knows?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Attachment

pgsql-patches by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: [PATCH] Using pread instead of lseek (with analysis)
Next
From: Andrew Dunstan
Date:
Subject: suggested warning about perl nested named subroutines