> I have run experiments to see how much faster SQLite might > work if it didn't invalidate its cache so quickly. The > answer is about 15%. So it is probably worth looking into > someday. Note that such a change will be backwards but > not forwards compatible. Suppose this change happened > for version 2.9.0. Then a 2.9.0 library would be able > to read and write a 2.8.13 database file, but a 2.8.13 > library would not be able to read and write a 2.9.0 > database file. Such a change it not to be made lightly > and without careful consideration.
I don't follow. Why would this cause compatibility issues? Presumably some benefit could be obtained just by not throwing away the cache at the SQLITE_READLOCK to SQLITE_UNLOCK transition, but waiting until the next SQLITE_UNLOCK to SQLITE_READLOCK transition. If at that time there have been no write transactions since the cache was created, it can continue to use it, otherwise it would then throw it away. Of course, that is just one example. If there was tracking of highest transaction on a per-table basis, and there was only one table's rows per page, then pages could be selectively invalidated on a per-page basis, not just the whole database. While I'm making suggestions despite near-total ignorance of sqlite :), have you measured what improvement would be obtained by using readonly mmap() for readers, rather read()? It would save some malloc churning as well as a memory copy. Performance could be additionally tweaked with madvise(SEQUENTIAL) when suitable. -mda --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
