On 14 Jul 2012, at 5:40am, Udi Karni <uka...@gmail.com> wrote: > It very easily handles billion row/100GB tables - multi-table joins, etc. - > it just chugs for a while because it's single threaded, and will gobble up > memory and swap - but it gets the job done.
... though you can, of course, do your SQLite call in a second thread and proceed as normal on your main thread. Still single-threaded but it won't block. I've noticed a lot of web pages which build the page, then fill in the contents of a table later. > It's quite amazing for a DB engine that's not even 1 MB. It's kept small partly because it's used in tiny single-core embedded systems: phone handsets, handheld control devices, and machine controllers. I even found a SQLite header in the firmware from my TV recorder. It has to run under tiny amounts of memory on simple hardware with little or no caching. What's interesting is that somehow a SQL engine designed for hand-sized devices is so good on standard desktop computers that many people use it. > While it's happiest when it can do all the work in memory versus disk - it > reads fairly quickly from disk the first time around - but not subsequently > - which is why I posed the question. This characteristic is something to do with your hardware or OS, not something inherent in SQLite. I bet if you tried the same thing on a Mac or Linux you wouldn't get the same behaviour. I seem to remember that Windows caches files with certain extensions specially, but I can't find any elucidation on the web. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
