From: drh PRAGMA auto_vacuum;
- Query or set the auto-vacuum flag in the database. PRAGMA auto_vacuum; Query or set the auto-vacuum flag in the database. Normally, when a transaction that deletes data from a database is
+ Normally, (that is to say when auto_vacuum is 0 or "none")
+ when a transaction that deletes data from a database is
committed, the database file remains the same size. Unused database file
- pages are marked as such and reused later on, when data is inserted into
- the database. In this mode the VACUUM
- command is used to reclaim unused space. When the auto-vacuum flag is set, the database file shrinks when a
- transaction that deletes data is committed (The VACUUM command is not
- useful in a database with the auto-vacuum flag set). To support this
- functionality the database stores extra information internally, resulting
- in slightly larger database files than would otherwise be possible. It is only possible to modify the value of the auto-vacuum flag before
- any tables have been created in the database. No error message is
- returned if an attempt to modify the auto-vacuum flag is made after
- one or more tables have been created.
+ pages are added to a "freelist" are reused for subsequent inserts. The
+ database file does not shrink.
+ In this mode the VACUUM
+ command can be used to reclaim unused space. When the auto-vacuum flag is 1 (full), the freelist pages are
+ moved to the end of the file and the file is truncated to remove
+ the freelist pages at every commit.
+ Note, however, that auto-vacuum only truncates the freelist pages
+ from the file. Auto-vacuum does not defragment the database nor
+ repack individual database pages the way that the
+ VACUUM command does. In fact, because
+ it moves pages around within the file, auto-vacuum can actually
+ make fragmentation worse. Auto-vacuuming is only possible if the database stores some
+ additional information that allows each database page to be
+ traced backwards to its referer. Therefore, auto-vacuuming must
+ be turned on before any tables are created. It is not possible
+ to enable or disable auto-vacuum after a table has been created. When the value of auto-vacuum is 2 (incremental) then the additional
+ information needed to do autovacuuming is stored in the database file
+ but autovacuuming does not occur automatically at each commit as it
+ does with auto_vacuum==full. In incremental mode, the separate
+ incremental_vacuum pragma must
+ be invoked to cause the vacuum to occur. The incremental vacuum mode
+ is not persistent. It must be set anew with each new database
+ connection. When a database with incremental vacuum is closed and
+ reopened, it comes up in auto_vacuum==full mode until explicitly
+ changed to incremental mode using this pragma. The database connection can be changed between full and incremental
+ autovacuum mode at will. However, the connection cannot be changed
+ in and out of the "none" mode after any table has been created in the
+ database.
-
PRAGMA auto_vacuum = 0 | 1;
+ PRAGMA auto_vacuum =
+ 0 | none | 1 | full | 2 | incremental;
PRAGMA incremental_vacuum(N);
+The incremental_vacuum pragma causes up to N pages to + be removed from the freelist. The database file is truncated by + the same amount. The incremental_vacuum pragma has no effect if + the database is not in + auto_vacuum==incremental mode + or if there are no pages on the freelist. If there are fewer than + N pages on the freelist, then the entire freelist is cleared.
+ +As of version 3.3.18 (the first version that supports + incremental_vacuum) this feature is still experimental. Possible + future changes include enhancing incremental vacuum to do + defragmentation and node repacking just as the full-blown + VACUUM command does. And + incremental vacuum may be promoted from a pragma to a separate + SQL command, or perhaps some variation on the VACUUM command. + Programmers are cautioned to not become enamored with the + current syntax or functionality as it is likely to change.
+PRAGMA legacy_file_format;
PRAGMA legacy_file_format = ON | OFF