* Tom Lane <tgl@sss.pgh.pa.us> [000612 19:37] wrote:
> Denis Perchine <dyp@perchine.com> writes:
> > No... You did not get me. I am talking about completly different thing:
> > I strace'ed postgres binary when doing queries and found out that it
> > do lseek after each read, and the difference in the position is 8096.
> > It means that we are in correct position anyway and do not need additional lseek.
>
> Oh. Hmm. Not sure if it's really worth the trouble, but you could try
> having fd.c keep track of the current seek position of VFDs when they
> are open as well as when they are closed, and optimize away the lseek
> call in FileSeek if the position is already right. You'd have to think
> carefully about what to do if a read or write fails, however --- where
> has the kernel left its seek position in that case? Possibly this could
> be dealt with by setting the internal position to "unknown" anytime
> we're not perfectly sure where the kernel is.
Have you thought of using pread/pwrite which are available on many
modern platforms:
ssize_t pread(int d, void *buf, size_t nbytes, off_t offset)
Pread() performs the same function, but reads from the specified position in the file without modifying the file
pointer.
I'm unsure how the postgresql system uses it's fds, however if they
are really shared via dup() or across fork/exec they will share
the same offset across multiple instances of the fd. The only way
around this behavior is to reopen the file in each process to get
a private offset.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."