On 25/02/2013 7:24 AM, Simon Slavin wrote:
On 25 Feb 2013, at 11:33am, Howard Chu <h...@symas.com> wrote:
Gabriel Corneanu wrote:
Following a few other discussions, I had the feeling that sqlite should
benefit from a cache which discards cached pages in a least frequently
used order.
Just offhand, classical LRU is quite poor in terms of lock overhead.
Gabriel writes "least frequently used". Howard writes "least recently used".
You're not writing about the same thing.
And the speed advantages of any algorithm used must be assessed before anything
new is implemented. SQLite is meant to be 'lite' and have almost nothing in.
Complicated algorithms and use-counting should be added only if they improve
things a lot.
(This is also partly a response to Howard, who suggests to just rely on
the OS fs cache)
There seem to be quite a few sqlite3 users on platforms where I would
not trust the OS to provide effective caching (embedded, smartphone,
etc.) and we have seen complaints on the list from them about slow I/O.
Granted, that's often due to logging overheads, but if we're going to
see any real benefit from some new caching strategy in sqlite3, it's
likely to show up there.
As for `lite', this could a pluggable extension, just like the fts
stuff. Lots of people don't need it, but it can be acquired if needed.
Ryan
P.S. locking overheads are a bogey-man on a belligerently
single-threaded system...
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
