Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Update the mmap documentation to describe the problem of Windows not truncating memory mapped files. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: |
fa77748670b476dbed62f56cebf144dd |
| User & Date: | drh 2014-01-30 15:56:45 |
Context
|
2014-01-30
| ||
| 17:41 | Fix FROM clause in the SELECT syntax diagrams. Also fix typos in the text. check-in: a115a033da user: drh tags: trunk | |
| 15:56 | Update the mmap documentation to describe the problem of Windows not truncating memory mapped files. check-in: fa77748670 user: drh tags: trunk | |
| 15:32 | Additional clarification on syntax restrictions in SELECT statements. check-in: 4c5d78209a user: drh tags: trunk | |
Changes
Changes to pages/mmap.in.
50 51 52 53 54 55 56 57 58 59 60 61 62 63 |
is not. Not all operating systems have a unified buffer cache.
In some operating systems that claim to have a unified buffer cache,
the implementation is buggy and can lead to corrupt databases.</p>
<li><p>Performance does not always increase with memory-mapped I/O. In fact,
it is possible to construct test cases where performance is reduced
by the use of memory-mapped I/O, though this is hard to do.</p>
</ol>
<p>Because of the potential disadvantages, memory-mapped I/O is turned
off by default. To activate memory-mapped I/O, use the [mmap_size pragma]
and set the mmap_size to some large number, usually 256MB or larger, depending
on how much address space your application can spare. The rest is
automatic. The [PRAGMA mmap_size] statement will be a silent no-op on
|
> > > > > > > > > > > > > |
50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 |
is not. Not all operating systems have a unified buffer cache.
In some operating systems that claim to have a unified buffer cache,
the implementation is buggy and can lead to corrupt databases.</p>
<li><p>Performance does not always increase with memory-mapped I/O. In fact,
it is possible to construct test cases where performance is reduced
by the use of memory-mapped I/O, though this is hard to do.</p>
<li><p>Windows is unable to truncate a memory-mapped file. Hence, on Windows,
if an operation such as [VACUUM] or [auto_vacuum] tries to reduce the
size of a memory-mapped database file, the size reduction attempt will
silently fail, leaving unused space at the end of the database file.
No data is lost due to this problem, and the unused space will be
reused again the next time the database grows. However if a version
of SQLite prior to 3.7.0 runs [PRAGMA integrity_check] on such a
database, it will (incorrectly) report database corruption due to
the unused space at the end. Or if a version of SQLite prior to 3.7.0
writes to the database while it still has unused space at the end, it
may make that unused space inaccessible and unavailable for reuse until
after the next [VACUUM].
</ol>
<p>Because of the potential disadvantages, memory-mapped I/O is turned
off by default. To activate memory-mapped I/O, use the [mmap_size pragma]
and set the mmap_size to some large number, usually 256MB or larger, depending
on how much address space your application can spare. The rest is
automatic. The [PRAGMA mmap_size] statement will be a silent no-op on
|