On Tue, Aug 6, 2013 at 10:21 AM, Simon Slavin <slav...@bigfraud.org> wrote:
> > On 6 Aug 2013, at 3:12pm, Bo Peng <ben....@gmail.com> wrote: > > > The problems we have only happens with large databases and it is > > difficult to create test cases to reproduce them. > > SQLite is not optimised for databases which contain a very large number of > tables (hundreds). It has to scan the long list of tables quite a lot. > This will lead to low speeds. > > SQLite uses hashing to find tables - no list scanning. However, when you do sqlite3_open(), SQLite has to read and parse the entire schema. SQLite is very efficient about that, but it does take time proportional to the size of the schema. Once the database is open, the schema is not read again (all schema lookups are via hash) unless some other process changes the schema, in which case the previous schema parse must be discarded and the whole thing read and parsed again. Detail: The schema parse does not happen during the call sqlite3_open(). Instead, sqlite3_open() sets a flag that indicates that the schema needs to be read, but the the actually reading and parsing is deferred until it is really needed. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users