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

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

In response to

Responses

Browse pgsql-patches by date

  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