The following PRAGMAs are available in the BDB SQL interface, but they behave differently in some way from standard SQLite.
The syntax for this PRAGMA is:
PRAGMA auto_vacuum PRAGMA auto_vacuum = 0 | NONE | 1 | FULL | 2 | INCREMENTAL
Standard SQLite does not allow you to enable or disable auto-vacuum after a table has been created. Berkeley DB, however, allows you to change this at any time.
In the previous syntax, 0
and
NONE
both turn off auto vacuuming.
1
or FULL
causes
full vacuuming to occur. That is, the BDB SQL interface will vacuum
the entire database at each commit using a very low
fill percentage (1%) in order to return emptied pages
to the file system. Because Berkeley DB allows you to call
this PRAGMA at any time, it is recommended that you do
not turn on FULL vacuuming because doing so can result
in a great deal of overhead to your transaction
commits.
If 2
or INCREMENTAL
is used, then incremental vacuuming is enabled. The
amount of vacuuming that is performed for incremental
vacuum is controlled using the following PRAGMAs:
PRAGMA bdbsql_vacuum_fillpercent |
PRAGMA bdbsql_vacuum_pages |
Note that you can call PRAGMA incremental_vacuum to perform an incremental vacuum operation on demand.
When performing vacuum operations, Berkeley DB defragments and repacks individual database pages, while SQLite only truncates the freelist pages from the database file.
For more information on auto vacuum, see PRAGMA auto_vacuum in the SQLite documentation.
Performs incremental vacuum operations on demand. You can cause incremental vacuum operations to be performed automatically using PRAGMA auto_vacuum.
Note that for SQLite, this PRAGMA is used to specify
the maximum number of pages to be freed during
vacuuming. For Berkeley DB, you use
PRAGMA bdbsql_vacuum_pages
instead.
For standard SQLite, this pragma identifies the maximum size that the journal file is allowed to be.
Berkeley DB uses multiple journal files, Berkeley DB journal files are different to a SQLite journal file in that they contain information about multiple transactions, rather than a single transaction (similar to the SQLite WAL journal file). Over the course of the database's lifetime, Berkeley DB will probably create multiple journal files. A new journal file is created when the current journal file has reached the maximum size configured using the journal_size_limit pragma.
Note that a BDB SQL interface journal file is referred to as a log file in the Berkeley DB documentation.