From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [PATCH] Using pread instead of lseek (with analysis) |
Date: | 2005-10-08 21:27:11 |
Message-ID: | 937.1128806831@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> What follows is the detailed analysis of the change. My conclusion is
> that on Linux at least where the syscall overhead is so low, it's not
> worth the change for performance. It is cleaner code-wise IMHO.
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.)
> What this tells me is that lseek time is swamped by actual read time,
> so not a major benefit in most cases.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-10-08 22:20:01 | Re: [PATCH] Using pread instead of lseek (with analysis) |
Previous Message | Tom Lane | 2005-10-08 20:26:19 | Re: [HACKERS] Kerberos brokenness and oops question in 8.1beta2 |