On Fri, 2005-06-17 at 20:16 -0400, Paul G wrote: > i'd like to hack sqlite3 to use shared memory for the page cache. >
A more useful hack, perhaps, would be to change the pager to use memmap() (when available) instead of read() and write(). This allows multiple instances of SQLite to use the same cache, essentially. The various pages might be mapped to different places in each process address space, but they would all point to the same physical page of memory. This would likely also make SQLite much faster even for the general case of just a single process since it would avoid the constant copying of information from kernel space to user space and back again. And you would still be able to write. The downside: You'll need to change the pager API around some, which means changes to the BTree layer. The current pager allocates some extra memory immediately before and after the data page. And it tracks each page using just a pointer to the data - since it can always find the header and tailer using pointer arithmetic. That won't work with memmap(). You'd have to relocate this extra stuff into a separate allocation which you then track separately. Also, you'll have to take out an exclusive lock on the database before making any changes to the data buffers in memory, not just before calling write() as in the current solution. That will cut your currency some because it means taking an exclusive lock much earlier in the write process. A new pager API that works for memmap() would also continue to work for the old read()/write() method. So presumably you could create a new pragma that lets the programmer decide at run-time which method to use. Use memmap() for faster reads and less memory usage or use read/write for better concurrency. -- D. Richard Hipp <[EMAIL PROTECTED]>
