Re: [PATCH] Using pread instead of lseek (with analysis)

On Sat, Oct 08, 2005 at 05:27:11PM -0400, Tom Lane wrote:
> How is it cleaner code-wise to debug and maintain two #ifdef'd code
> paths instead of one? (And when I say "debug", I mean "I don't believe
> FileSeek still works". One reason that the patch seems unmaintainable
> to me as-is is that it creates a subtle, critical, and undocumented
> difference in the semantic meaning of the seekPos variable: in one case
> it's tracking the kernel's own seek position, and in the other it isn't.)

I mean in the situation where we would only use pread. As for the
difference, no code outside of fd.c can assume anying about the kernel
seek position because it can't see it (the file might be closed!).
Unless something bypasses the abstraction?

> 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.

I satisfied my curiosity and showed it just isn't worth it at this
point.
--
Martijn van Oosterhout <kleptog(at)svana(dot)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.