On Fri, Sep 12, 2014 at 8:07 PM, Simon Slavin <slav...@bigfraud.org> wrote:
> > one thing that annoys me about SQLite is that it needs to make a > journal file which isn't part of the database file. Why ? Why can't it > just write the journal to the database file it already has open ? This > would reduce the problems where the OS prevents an application from > creating a new file because of permissions or sandboxing. > Where in the database does the journal information get stored? At the end? What happens then if the transaction is an INSERT and the size of the content has to grow? Does that leave a big hole in the middle of the file when the journal is removed? During recovery after a crash, where does the recovery process go to look for the journal information? If the journal is at some arbitrary point in the file, where does it look. Note that we cannot write the journal location in the file header because the header cannot be (safely) changed without first journaling it but we cannot journal the header without first writing the journal location into the header. One idea that might work is to interleave the journal information with the content. So for each page in the database, there is a corresponding page of journal content. The downside there is that you double the size of the database file without increasing its storage capacity. > > Similarly, temporary indexes and temporary tables (I think) also go in > external files. I don't see why, if they're part of 'main', they can't go > in the main file. > > Temporary tables and indexes are only suppose to be visible to the one database connection that created them, not to all database connections. So they cannot be put into the main database file where they would be visible to everybody. There are also performance reasons for separating the temporary tables and indexes. Because temporary tables do not have to be preserved across a system crash, SQLite is able to take lots of short-cuts when writing temporary tables (for example: omitting fsync() calls) which make them run must faster. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
