When you issue the VACUUM statement, the OS ends up loading a lot of the data from the database into its disk cache. Since you're running the select right afterwards, then SQLite ends up loading the pages from the underlying OS cache, so ya its going to *appear* faster than if you had issued an autovacuum.
Robert > -----Original Message----- > From: Tobias_Rundström [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 22, 2006 3:01 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Vacuum slow > > > El 02-03-2006, a las 13:35, [EMAIL PROTECTED] escribió: > > The VACUUM command does something very much like this: > > > > sqlite3 olddb .dump | sqlite3 newdb; mv newdb olddb > > > > I say "much like" the above because there are some important > > differences. The VACUUM command transfers the data from > the old and > > new database in binary without having to convert it into text. And > > the whole operation is protected by a rollback journal so that if a > > power failure occurs in the middle, the operation will rollback. > > > > But the point is this: VACUUM recreates the whole database from > > scratch. The time required is proportional to the amount > of data that > > is in the database. > > I have noticed that when I import a lot of data (40-50k rows) > into my application and run a select (fairly complex with > joins) afterwards it will be a bit slow (fragmented indexes > or something), but rerunning the select after a vacuum; will > *GREATLY* speed up matters. > This doesn't seem to happen if I set the autovacuum flag, > vacuum still seems to do something different. > > Any ideas? > > -- Tobia???? =0
