Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Minor edits to the WAL document. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
f84c08f7bfe1c2680bf98199676896e0 |
User & Date: | drh 2010-06-17 15:21:47.000 |
Context
2010-06-19
| ||
10:39 | Updates to the fileformat2 document. (check-in: 2a5bc288a1 user: drh tags: trunk) | |
2010-06-17
| ||
15:21 | Minor edits to the WAL document. (check-in: f84c08f7bf user: drh tags: trunk) | |
2010-06-15
| ||
12:50 | Add the new book by Kay Droessler to the "Books About SQLite" page. (check-in: 089a50e46d user: drh tags: trunk) | |
Changes
Changes to pages/wal.in.
︙ | ︙ | |||
8 9 10 11 12 13 14 | Beginning with [version 3.7.0], a new "Write-Ahead Log" option (hereafter referred to as "WAL") is available.</p> <p>There are advantages and disadvantages to using WAL instead of a rollback journal. Advantages include:</p> <ol> | | | 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | Beginning with [version 3.7.0], a new "Write-Ahead Log" option (hereafter referred to as "WAL") is available.</p> <p>There are advantages and disadvantages to using WAL instead of a rollback journal. Advantages include:</p> <ol> <li>WAL is significantly faster in most scenarios. <li>WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently. <li>Disk I/O operations tends to be more sequential using WAL. <li>WAL uses many fewer fsync() operations and is thus less vulnerable to problems on systems where the fsync() system call is broken. </ol> |
︙ | ︙ | |||
31 32 33 34 35 36 37 | <li>All processes using a database must be on the same host computer; WAL does not work over a network filesystem. <li>Transactions that involve changes against multiple [ATTACH | ATTACHed] databases are atomic for each individual database, but are not atomic across all databases as a set. <li>With WAL, it is not possible to change the database page sizes using [VACUUM] or when restoring from a backup using the [backup API]. | > | | | 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 | <li>All processes using a database must be on the same host computer; WAL does not work over a network filesystem. <li>Transactions that involve changes against multiple [ATTACH | ATTACHed] databases are atomic for each individual database, but are not atomic across all databases as a set. <li>With WAL, it is not possible to change the database page sizes using [VACUUM] or when restoring from a backup using the [backup API]. <li>WAL might be very slightly slower (perhaps 1% or 2% slower) than the traditional rollback-journal approach in applications that do mostly reads and seldom write. <li>There is an additional persistent "*-wal" file associated with each database, which can make SQLite less appealing for use as an [application file-format]. <li>There is the extra operation of [checkpointing] which, though automatic by default, is still something that application developers need to be mindful of. </ol> |
︙ | ︙ |