Thanks Igor and Simon for your inputs. I was under the impression that VACUUM would also help performance since it does defragmentation.
On Tuesday, 10 December 2013 3:02 PM, Simon Slavin <slav...@bigfraud.org> wrote: On 10 Dec 2013, at 8:04pm, veeresh kumar <veeru...@yahoo.com> wrote: > -If we put inside a transaction, definitely we would get a SQLITE_BUSY > error.Any way to avoid this error? It is normal for SQL engines to prevent VACUUM inside a transaction, and to lock the database from other threads/processes/users while it operates. For instance, Postgres will issue a consistent error message if you don't close your transaction before you do a VACUUM. Since it is not a 'real' SQL command (in that it operates on file structure, not tables, rows or columns) it shouldn't be a part of a transaction. Don't forget what VACUUM does: it doesn't operated just on data in the database, it reorganises the entire database file, and can move every thing into a different place and delete entire pages. It can even change _rowid_s. no way it can operate while allowing other SQL commands to work, so it may as well issue an explicit lock. > The database size that we use in the application can grow upto 50 GB. A 50GB database in SQLite is no problem, and no reason to run VACUUM. The time to run VACUUM is when (a) space is at a premium, or you need to take copies and (b) VACUUM will save significant space Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
