Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Martijn van OosterhoutDate: 2005-10-08 22:20:01
Subject: Re: [PATCH] Using pread instead of lseek (with analysis)
Previous:From: Tom LaneDate: 2005-10-08 20:26:19
Subject: Re: [HACKERS] Kerberos brokenness and oops question in 8.1beta2

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group