Documentation Source Text

Check-in [fa77748670]
Login

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.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: fa77748670b476dbed62f56cebf144dd175c5ecc
User & Date: drh 2014-01-30 15:56:45.740
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
Unified Diff Ignore Whitespace Patch
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
︙︙