Aha, great! So what I was asking for was already in the box, and a mmap_size of say 2^63 will be fine then!
One reason that I asked for this was that I want to use it on OpenBSD, and there, mmaping in Sqlite is disabled altogether, in the absence of a unified buffer cache (UBC) in the OS. If I just force it on (by hacking the build script), as long as mmap_size always is 2^63, will Sqlite access the file via memory accesses only, and never using fread/fwrite which would lead to undefined behavior because of the absence of a UBC? Thanks! On Tuesday, 3 May 2016, Scott Hess <shess at google.com> wrote: > 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 > <javascript:;>> 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 <javascript:;> > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org <javascript:;> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
