On 9 May 2012, at 1:30pm, Navaneeth.K.N <navaneet...@gmail.com> wrote:
> On Wed, May 9, 2012 at 5:15 PM, Simon Slavin <slav...@bigfraud.org> wrote: > >> >> Sure. That would cache the data. And then the next thing that needs to >> be cached might overwrite it all again. You're messing with something that >> your OS thinks it has sole control over. >> > >>> Are there any API functions that will tell how many pages are currently >>> cached, cache misses etc..? >> >> The problem with this is it will change from run to run. Sometimes your >> program will be the only thing running. Other times other apps will be >> open. Sometimes they'll be printing in the background. Sometimes the OS >> will be defragging in the background. Sometimes a virus-checker will >> spring into action. Sometimes the computer will be left idle and a >> screensaver will start up. > > I think I am missing something here. > > I was thinking that caching of pages is SQLite's implementation and nothing > to do with the OS. I'd think the cache is associated with each database > connection and Sqlite caches all the pages it reads until the maximum > limit. Is this the correct understanding? Details of what SQLite caches, how much space it can use for caching, whether there are separate caches for each database, each connection, or each table, are undocumented. In other words, don't depend on any particular behaviour, and even if you've figured out what the behaviour is for this version, it may change for the next version. The only thing you know about caching is this: <http://www.sqlite.org/pragma.html#pragma_cache_size> So you can set a cache size. But you have no idea how SQLite will use that space. There's also this: <http://sqlite.org/sharedcache.html> And that doesn't answer your questions either. uIf you want SQLite to use some memory for data, use an in-memory database. That's what they're for. SQLite provides a very specific tool for "I want this data in memory.". You don't have to muck about trying to subvert the use of caching, which is meant for other purposes. > If yes, how will other > applications starting or doing some work in background affects SQLite's > cache? > > When documentation says SQLIte caches pages, are we talking about operating > system level paging and caching? Multitasking operating systems like Windows, Unix, Linux and OS X swap entire applications to disk. The application may have reserved some memory for something, but that 'memory' might actually be paged out to backing store (usually the boot disk). You have no control over this, and nor does the app. So even if SQLite thinks something is in RAM, it might actually be on backing store. > I thought about in memory databases. But technically, caching pages at > SQLite level or using an in-memory database makes no difference here, > rigtht? An in-memory database represents memory that SQLite will use for that database's information and nothing else. Caching is something you have no control over. Without reading the source code for your version of SQLite you have no idea what SQLite will use its cache space for, or when it will decide to use the space it has available for something else. There's no point in doing a "SELECT * FROM myTable" to force the table into cache if the next thing SQLite does is use the cache for other purposes. > BTW, this database is used only for reads. Writes are performed only one time. Then a simple import of the entire database into reserved memory as your app starts will do all you need. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
