Re: Caching number of blocks in relation to avoi lseek.

Denis Perchine <dyp(at)perchine(dot)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.

regards, tom lane