The existing mmap functionality only maps the actual blocks associated with the file. So if your file is 16kb and your mmap_size is 1GB, only 16kb is used. Unless you add data to the file, then the mmap area grows, obviously.
-scott On Mon, May 2, 2016 at 2:01 AM, Mikael <mikael.trash at gmail.com> wrote: > Dear Dr. Hipp & list, > > What about making Sqlite's memory mapping adapt to the current database > size, in increments of say 100MB? > > The at least 48 bits (256TB) of addressing space that modern 64bit > architectures give per process is not suffering any risk of depletion, as > long as the space not is used wastefully, which would be the case now as > today in the absence of an incremental setting, to guarantee that a > database never will grow outside of the mmap size, a developer is tempted > to set mmap_size to a value so high that it guaranteedly never will be > reached e.g. 1TB, and that way an application could be almost 100% wasteful > with address space, and that way a process would get a constraint of max > 200 or so databases. > > Can Sqlite user code implement this by itself already somehow? > > This would also be useful to do memorymapped-only IO on an OS that not has > a unified buffer cache, such as OpenBSD, where memory mapping is disabled > altogether for this reason currently. > > Looking forward to your response, > > Thanks, > Mikael > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
