> 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.
If read or write fails. Position will left the same. This situation is already tracked
in File routines, but a little bit incorrectly.
Here is the full patch for this. This patch reduce amount of lseek call ten times
for update statement and twenty times for select statement. I tested joined update
and count(*) select for table with rows > 170000 and 10 indices.
I think this is worse of trying. Before lseek calls account for more than 5% of time.
Now they are 0.89 and 0.15 respectevly.
Due to only one file modification patch should be applied in src/backedn/storage/file/ dir.
--
Sincerely Yours,
Denis Perchine
----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------
