On Thu, Apr 4, 2013 at 9:02 AM, Ryan Johnson <ryan.john...@cs.utoronto.ca>wrote:
> On 04/04/2013 8:02 AM, 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. >> > Nice! > > Some quick thoughts: > > 1. Does this replace the page cache completely, or does it just turn > "read" and "write" into glorified memcpy calls? I would assume the latter > so that virtual tables continue to work? > No. The page cache is still there. > > 2. Does sqlite3 attempt to map the entire database file, and what happens > with large files in 32-bit processes? > It mmaps the first N bytes of the database file where N is configurable. The default N at the moment is 256MiB. You can change it to 0 or to as big of a number as you want using a PRAGMA. > > 3. It seems like this would increase the "attack surface" for stray > pointers in the host program. Granted, writes to stray pointers are not > sqlite's fault, but they're an unfortunately common problem... and mmap > makes user bugs more likely to directly corrupt the database on disk. > Perceived reliability might drop as a result (I'm not arguing that the risk > is worth giving up 2x, just pointing it out as a potential unintended > consequence). > > Thoughts? > Ryan > > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
