Hello Mats,

I've run into exactly the same thing on both version 2 and 3,
commented on it here before too. What Someone suggested here and it
works, is to initially open and read the file as if it were a data
file. I do it 64K at a time. Then close it and open with sqlite, in my
case that took the 30 second initial stall and dropped it to about 1-2
seconds. I haven't tried memory mapping and scanning forward but, that
might work too. The DB where it had the most affect is about 10 megs.

This seems to pre-load the windows file cache.

C


Monday, May 1, 2006, 5:25:23 AM, you wrote:

MG> Hi,

MG> We ran into an interesting "feature" with SQLite recently. We're
MG> building a large and complex system which uses a MySQL database; but in
MG> case of a network failure we also build a backup SQLite database every
MG> night and transfer to the client. So when the network goes kaboom
MG> (which, unfortunately, happens), the application seamlessly switches to
MG> the local SQLite database and the users rarely notice anything at all.

MG> However, we noticed an interesting thing. When we first open the SQLite
MG> database and start running queries on it, the first query always takes
MG> an enormous time to complete: up to 30-45 seconds. It's not a really
MG> complex query, mainly just a lookup from a large table, and subsequent
MG> queries typically run in less than 200 milliseconds. But we've been
MG> totally unable to explain this initial delay. And, furthermore, when we
MG> vary the query, sometimes there's additional delays of similar time
MG> before everything runs smoothly again.

MG> It almost seems like the first time we use a particular index, the
MG> entire index is rebuilt on-the-fly, and then, after that, it is used.
MG> But we've been unable to spot any differences in the binary files.

MG> Since our database framework presently do not have support for the 3.x
MG> branch, we're using version 2.8.17. The database generated every night
MG> by one of our nightly processes is typically 50-80 MB in size.

MG> Any light upon what goes wrong would be much appreciated. :)

MG> regards,
MG> Mats Gefvert
MG> Visionutveckling AB





-- 
Best regards,
 Teg                            mailto:[EMAIL PROTECTED]

Reply via email to