Re: Caching number of blocks in relation to avoi lseek. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Caching number of blocks in relation to avoi lseek.
Date
Msg-id 6002.960863681@sss.pgh.pa.us
Whole thread Raw
In response to Re: Caching number of blocks in relation to avoi lseek.  (Denis Perchine <dyp@perchine.com>)
Responses Re: Caching number of blocks in relation to avoi lseek.
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal for fixing intra-query memory leaks
Next
From: Tom Lane
Date:
Subject: Re: memory management suggestion