On Fri, Feb 7, 2014 at 1:01 PM, varro <varro@nodomain.invalid> wrote:
> Regarding the following old post: > > Richard Hipp wrote: > > By making use of memory-mapped I/O, the current trunk of SQLite (which > will > > eventually become version 3.7.17 after much more refinement and testing) > > can be as much as twice as fast, on some platforms and under some > > workloads. We would like to encourage people to try out the new code and > > report both success and failure. Snapshots of the amalgamation can be > > found at > > > > http://www.sqlite.org/draft/download.html > > > > Links to the relevant documentation can bee seen at > > > > http://www.sqlite.org/draft/releaselog/3_7_17.html > > > > The memory-mapped I/O is only enabled for windows, linux, mac OS-X, and > > solaris. We have found that it does not work on OpenBSD, for reasons we > > have not yet been able to uncove; but as a precaution, memory mapped I/O > is > > disabled by default on all of the *BSDs until we understand the problem. > > Was the problem ever identified? > OpenBSD lacks a coherent filesystem cache. That is to say, changes to a file made using write() are not necessarily reflected in mmap-ed memory right away. And change to a mmap-ed segment are not necessarily reflected in subsequent read() operations. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
