I agree that adding this to the library, and making it accessible via a pragma command would be very useful. For example, pragma commitrate 1000 would test the commit rate of 1000 commits and return the results in transactions per second as a row.
If I install my app on a client's machine, I could run this test periodically to ensure that the system environment is going to support "no corruption" operation, and/or send some kind of warning to my customer that there is a risk of corruption because their system environment has problems. If it were only an external program bundled with sqlite, I couldn't really make use of it, because I'd have to distribute the program and instructions how to use it, and rely on customers to actually do it. This is a pretty small function. Just for my own use, I'd consider foreign key support to be way more bloated that this. Jim On 5/29/09, Marcus Grimm <mgr...@medcom-online.de> wrote: >> On Thu, May 28, 2009 at 03:12:55PM -0700, Allen Fowler scratched on the >> wall: >>> >>> > just for anybody who is interested: >>> >>> > >>> > I translated Jim's function into window code and added >>> > a page of 1024 that will be written, instead of a single byte. >>> > On my Win-XP system I got 55 TPS, much faster than sqlite >>> > seems to write a page but that might be related to the >>> > additional overhead sqlite needs to do. > > just to add: I traced a little what sqlite does when an > simple UPDATE is done within a transaction: It does > two syncs on the journal file and one final sync on the > db itselve, so achieving something like 15 TPS is reasonable. > > >>> > >>> > This brings me to a nice to have feature request: >>> > How about adding similar test function in the sqlite API ? >>> > This might use the vfs to write pages and gives some feedback >>> > on the performance of the system where sqlite runs on. >>> > It might also detect problems with the commit function... >>> > Just an idea... >>> > >>> >>> Interesting idea. >> >> It would make a lot more sense to make this an external utility >> or an extension of the sqlite3 shell. Adding it to the core library >> is a definite case of code bloat. > > Adding it into the API would allow my application to > easily make the test for example the first time it runs > on a system. But maybe a problem for the users that > apply a sqlite wrapper. > However, having it in sqlite3 shell would be very useful as > well. > > Marcus > >> >> Actually, a whole suite of performance related tests might be >> interesting. >> >> -j >> >> -- >> Jay A. Kreibich < J A Y @ K R E I B I.C H > >> >> "Our opponent is an alien starship packed with atomic bombs. We have >> a protractor." "I'll go home and see if I can scrounge up a ruler >> and a piece of string." --from Anathem by Neal Stephenson >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > > > _______________________________________________ > 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
