Yes, good point. If you partition the database into multiple databases, you will have to place each on its own physical disk drive to increase transaction rates. If your base transaction rate with one drive is T, with N drives it should be N*T; 4 drives gives you 4x the transaction rate, etc. Each of the drives has to be completely independent - no filesystems crossing drives.
If you partition into multiple databases and keep them on the same drive, your transaction rate will likely go down, because now you are introducing seeks back and forth between the two databases as you commit. I think someone mentioned using the journal_data option with ext3 to increase performance. In theory, it possibly could, but on my Linux system, it didn't. I got the same results when I tried using tune2fs to change it, though I'm not sure it actually did anything. Jim On 6/11/09, Petite Abeille <petite.abei...@gmail.com> wrote: > > On Jun 11, 2009, at 4:53 PM, Sam Carleton wrote: > >> I am a late comer to this discussion, so this might have already >> been purposed... > > Additionally, if this was not mentioned already, you can partition > your database across multiple physical files through the magic of > 'attach database' or something and load balance across those. > > http://en.wikipedia.org/wiki/Partition_(database) > > CHeers, > > -- > PA. > http://alt.textdrive.com/nanoki/ > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Software first. Software lasts! _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
