Mikael wrote: > On Tuesday, 3 May 2016, Richard Hipp <drh at sqlite.org > <javascript:_e(%7B%7D,'cvml','drh at sqlite.org');>> wrote: > >> On 5/2/16, Mikael <mikael.trash at gmail.com> wrote: >>> >>> 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? >>> >> >> SQLite only reads using mmap. Write always happen using the write() >> (or pwrite()) system call. So it will never work on OpenBSD. >> >> The database file is mmap-ed read-only. This is so that stray >> pointers in the application cannot trivially corrupt the database >> file. > > > Aha. > > What do you say about the idea of a memory access only mode, enabled > with SQLITE_MMAP_NO_FILEIO on any OS, for the daring users who want that?
It's certainly an avenue to getting functionality in OpenBSD. In general, e.g. on Linux, there's not much to gain from it. There is a small performance gain when all of your data fits in RAM. There is a larger performance loss when your DB is larger than RAM - every time you touch a page to write to it, if it's not already memory-resident, the OS faults it in from disk. It's a wasted page fault if you were simply going to overwrite the entire page (which e.g. LMDB does). If you update pages in-place, instead of doing COW as LMDB does, it may or may not be a wash, I haven't measured that use case. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
