Hi Jens, thanks for your reply.
2GB still still seems reasonable as a default, since SQLite is not primarily targeted at servers with oodles of RAM. (Remember, "64-bit" includes nearly all current mobile phones/tablets, which still have small amounts of RAM, 2GB or less.)
My comment about 32bit vs 64bit wasn't really about the ram available on the system, just about integer sizes and the address space available for an mmap.
For instance - if you have a 30GB db file on a 64bit system with <= 2GB ram, you can still mmap the whole file, and benefit from that mmap. If the portion of the db that gets used for a query fits within the available pagecache ram, it's a clear win. (It's not like the whole file automatically gets read from disk into the pagecache for the mmap.)
But even if the whole file is used for the query (that is, more than fits into pagecache/ram), it still has the benefit of avoiding the system calls for the file seeks/reads. (Either way the kernel needs to swap disk pages into/out of of the pagecache.)
What's more, (if I understand correctly) the default SQLITE_DEFAULT_MMAP_SIZE is zero on all platforms, so mmap_size starts at 0 unless raised with the PRAGMA at runtime. So applications need to explicitly request when they want to do mmaps of a particular size. So my question is, at least on on 64bit platforms, why is the default to *prevent* manually raising mmap_size past 2GB at runtime?
I guess I'm curious what the rationale is for this hard limit.
You can easily override the default by #defining a higher value yourself, right?
Yes, of course, I compile my own now, defining a higher SQLITE_MAX_MMAP_SIZE. But when I want to run an application (eg, the sqlite3 command line util or or the python library) across many systems that I don't control, it would be convenient if I could use the stock versions installed rather than having to compile my own everywhere.
Again the question I'm curious about is, why should users have to compile their own versions just to be able to raise PRAGMA mmap_size at runtime?
Thanks..! Carl _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
