On Tue, Aug 10, 2010 at 05:46:26PM -0700, Paweł Hajdan, Jr. wrote: > So this is another chromium patch I'd like to submit: > http://src.chromium.org/viewvc/chrome/trunk/src/third_party/sqlite/preload-cache.patch?revision=26596&view=markup > > I'm not the author of that one, but the main idea seems to be that with > preloading we get better performance with many scenarios chromium uses > sqlite (like for omnibox local suggestions). What do you think about the > patch and the idea? Is there better way to do the same thing? Would you like > to see some benchmarks?
I thought about something like that. I took a little different approach: I've put posix_fadvise(fd, 0, 0, POSIX_FADV_WILLNEED) just after opening the database file and in my case with a fragmented database (may insert/update/delete without vacuum) and cold page it was a huge difference. Using posix_fadvise() is asynchronous without any separate thread and opening the database isn't slowed down - you don't need to wait until the file is loaded. I'm interested in speeding up SQLite when opening a database that is not in the OS's page cache. Next thing I want to try is to preload only selected tables/indexes with help of posix_fadvise(). I want to call posix_fadvice for every child page when traveling through the btree just before moving down to the first child of the current page. I hope this will be faster that a regular table/index read because the OS/disk will have the IO queue full and can reorder read requestes if necessary. It will be slower than preloading the whole DB, but I don't want to waste disk bandwidth for that. -- Damian Pietras http://www.linuxprogrammingblog.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
