Re: performance: use pread instead of lseek+read - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: performance: use pread instead of lseek+read
Date
Msg-id 200303062107.h26L7Lb02958@candle.pha.pa.us
Whole thread Raw
In response to Re: performance: use pread instead of lseek+read  (Manfred Spraul <manfred@colorfullife.com>)
List pgsql-patches
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >BSD/OS doesn't have pread either.  Isn't pread() just a case of merging
> >two system calls into one?  Does a single system call cause that much
> >overhead?  I didn't think so.
> >
> >
> As I wrote, in a microbenchmark lseek+read(,8192) was 10% slower than
> pread(,,8192).
>
> >Doesn't pread() do the lseek() internally anyway.
> >
> No. pread doesn't use the file pointer at all.
> This is a  huge advantage if fds are shared: Two threads/processes can
> read simultaneously from the same fd. This is impossible without pread -
> there is only one file pointer, the threads would trash each others state.
>
> Since postgresql doesn't share fds, the only advantage for postgresql is
> the lower syscall overhead.

Yes, I can imaging having file descriptors shared like that would be a
big win, and I guess that's why it is called pread (pthread).  Anyway,
for us, it does seem like just a merged lseek/read() call, and because
we can avoid the lseek() sometimes, I wonder if our code may be faster
sometimes.  I can also imagine the separate lseek()/read() calls to be
better optimized by the kernel because a read with out an lseek is more
clearly sequential.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: psql \pset pager always for 7.3.2 (patch)
Next
From: Peter Eisentraut
Date:
Subject: Re: new format for describe (repost #2)