Re: [sqlite] Any way to disable journaling & rollback?
Thank you for pointing out the omitJournal argument to sqlite3BtreeFactory! That's just what I was looking for. By forcing omitJournal to 1 in all cases (thereby always turning off journaling), I was able to increase the total speed of my application by a factor of 2.5 over the speed I got by just removing the call to FlushFileBuffers (which by itself provided a speed-up factor of 20). So by removing journaling, my application runs 50 times as fast as it does with journaling enabled! I don't know how much write performance matters to others, but increasing the speed of an application by a factor of 50 is worth looking into. Aladdin Lamp wrote: In order to disable totally journaling, I think (to be confirmed by real sqlite experts though) that you could patch each 4 calls to the function: int sqlite3BtreeFactory(const sqlite3 *db, const char *zFilename, int omitJournal, int nCache, int flags, Btree **ppBtree); using always 1 as the third parameter (omitJournal) instead of 0 in the following files: - attach.c (line 136) - build.c (line 3212) - main.c (line 1025) (- and in vdbe.c (line 2611) but omitJournal argument already equals 1 in this file) Keep us informed if this works. Aladdin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any way to disable journaling & rollback?
Phil, In order to disable totally journaling, I think (to be confirmed by real sqlite experts though) that you could patch each 4 calls to the function: int sqlite3BtreeFactory(const sqlite3 *db, const char *zFilename, int omitJournal, int nCache, int flags, Btree **ppBtree); using always 1 as the third parameter (omitJournal) instead of 0 in the following files: - attach.c (line 136) - build.c (line 3212) - main.c (line 1025) (- and in vdbe.c (line 2611) but omitJournal argument already equals 1 in this file) Keep us informed if this works. Aladdin > From: [EMAIL PROTECTED] > To: sqlite-users@sqlite.org > Date: Fri, 11 Apr 2008 17:45:35 -0500 > Subject: Re: [sqlite] Any way to disable journaling & rollback? > > Holding commits with a timeout is a feasible solution. However, in my > application it is somewhat complex to implement. Multiple threads are > accessing the database, and read requests usually run in a different thread > than writes. I don't want reads to be blocked while a commit timeout waits, > so a read would have to force a commit. I don't think one thread can commit > transactions for another thread, so I would have to set up an inter-thread > queueing system to allow readers to notify writers in different threads that > commits need to be done. Since commits are done in multiple places, this > approach will get messy fast. > > I think removing the FlushFileBuffers call (which is normally done on every > commit) is the best solution. It is not as fast as totally turning off > journaling, but it allows my program to run 20 times faster without the > complexity of trying to hold commitments. Also, journaling _is_ being done > (just not forced to the disk). So if my application crashes but Windows > continues to run, the journaling will eventually get flushed from Windows > cache to disk, and it should be available for a rollback. > > If I can figure out how to totally turn off journaling, I will do some > timing tests to see how much that speeds things up. It certainly won't be a > factor of 20, but a factor of 2 is possible. > > A new pragma "journaling=[off|on]" would be nice. > > Key wrote: > > Removing the journalling will certainly cause you lots of grief in the event > of a "crash"... > > You could do the following, > The write code (inserts) will queue incoming data into an > "array/storage in memory etc..." > When the first row is captured set a timer. > When either the timer expires or you reach a row limit threshold, > write the data to sqlite in a batched transaction. > > This way you get good performance and reliablity! But if you code crashes > and > you don't keep persistent what was in memory you'll loose that data. > You'll probably need to do some tuning of the timer/row limits to get a > balance between performance > and potential data loss. > > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _ Avec Hotmail, vos e-mails vous suivent partout ! Mettez Hotmail sur votre mobile ! http://www.messengersurvotremobile.com/?d=hotmail ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any way to disable journaling & rollback?
Phil, Yes its complicated. Yes its doable! But if you want performance its going to be a bit complicated. Sqlite does not allow concurrent read/write even from multiple threads! Step back a bit, I've answered the question: yes you may disable journalling. But the real problem your having is concurrency and performance. Disabling journalling will get you into big trouble! So that really isn't an option, forget about that!!! So the only thing left is the performacnce... Try my suggestion, you might be surprised in that it doesn't take that much more time to write 10 records vs one! Another solution to the issue might be a condition variable that you could kick from the reader thread! Thus if a reader really needs to read, the blocking write thread could catch the cv/mutex and wake up, commit allowing the reader to sleep. Now that you've opened the threading can of worms take a look an the "shared cache" feature! This might be very helpful to you. I think there was some mention of reading dirty pages?? This might be just the ticket for your app!! Phil Sherrod <[EMAIL PROTECTED]> wrote: Holding commits with a timeout is a feasible solution. However, in my application it is somewhat complex to implement. Multiple threads are accessing the database, and read requests usually run in a different thread than writes. I don't want reads to be blocked while a commit timeout waits, so a read would have to force a commit. I don't think one thread can commit transactions for another thread, so I would have to set up an inter-thread queueing system to allow readers to notify writers in different threads that commits need to be done. Since commits are done in multiple places, this approach will get messy fast. I think removing the FlushFileBuffers call (which is normally done on every commit) is the best solution. It is not as fast as totally turning off journaling, but it allows my program to run 20 times faster without the complexity of trying to hold commitments. Also, journaling _is_ being done (just not forced to the disk). So if my application crashes but Windows continues to run, the journaling will eventually get flushed from Windows cache to disk, and it should be available for a rollback. If I can figure out how to totally turn off journaling, I will do some timing tests to see how much that speeds things up. It certainly won't be a factor of 20, but a factor of 2 is possible. A new pragma "journaling=[off|on]" would be nice. Key wrote: Removing the journalling will certainly cause you lots of grief in the event of a "crash"... You could do the following, The write code (inserts) will queue incoming data into an "array/storage in memory etc..." When the first row is captured set a timer. When either the timer expires or you reach a row limit threshold, write the data to sqlite in a batched transaction. This way you get good performance and reliablity! But if you code crashes and you don't keep persistent what was in memory you'll loose that data. You'll probably need to do some tuning of the timer/row limits to get a balance between performance and potential data loss. ___ 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
Re: [sqlite] Any way to disable journaling & rollback?
Holding commits with a timeout is a feasible solution. However, in my application it is somewhat complex to implement. Multiple threads are accessing the database, and read requests usually run in a different thread than writes. I don't want reads to be blocked while a commit timeout waits, so a read would have to force a commit. I don't think one thread can commit transactions for another thread, so I would have to set up an inter-thread queueing system to allow readers to notify writers in different threads that commits need to be done. Since commits are done in multiple places, this approach will get messy fast. I think removing the FlushFileBuffers call (which is normally done on every commit) is the best solution. It is not as fast as totally turning off journaling, but it allows my program to run 20 times faster without the complexity of trying to hold commitments. Also, journaling _is_ being done (just not forced to the disk). So if my application crashes but Windows continues to run, the journaling will eventually get flushed from Windows cache to disk, and it should be available for a rollback. If I can figure out how to totally turn off journaling, I will do some timing tests to see how much that speeds things up. It certainly won't be a factor of 20, but a factor of 2 is possible. A new pragma "journaling=[off|on]" would be nice. Key wrote: Removing the journalling will certainly cause you lots of grief in the event of a "crash"... You could do the following, The write code (inserts) will queue incoming data into an "array/storage in memory etc..." When the first row is captured set a timer. When either the timer expires or you reach a row limit threshold, write the data to sqlite in a batched transaction. This way you get good performance and reliablity! But if you code crashes and you don't keep persistent what was in memory you'll loose that data. You'll probably need to do some tuning of the timer/row limits to get a balance between performance and potential data loss. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any way to disable journaling & rollback?
DRH, I would be seriously interested in a PRAGMA to disable/avoid a journal file as in my application I don't need it at all and it only slows down my DB writes. Would it be possible to add this? If so, thanks in advance. RBS -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Griggs, Donald Sent: 11 April 2008 14:06 To: General Discussion of SQLite Database Subject: Re: [sqlite] Any way to disable journaling & rollback? Regarding: " removing the call of FlushFileBuffers for each transaction made my application run 20 times faster." Since you don't need the integrity protection that transactions afford, would you not get the same performance gain using the standard source and setting SYNCHRONOUS to zero? This email and any attachments have been scanned for known viruses using multiple scanners. We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. ___ 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
Re: [sqlite] Any way to disable journaling & rollback?
Yes the OS buffers, my error.. My point was that a close happens when sqlite commits. Which means that the OS will attempt to write the buffers to disk and in all likely hood some of the buffers will make it to disk this is I/O. Then the file is deleted aka commit! Regards, Ken "Jay A. Kreibich" <[EMAIL PROTECTED]> wrote: On Fri, Apr 11, 2008 at 09:08:04AM -0700, Ken scratched on the wall: > Even with Synchronous = off > > Sqlite will flush its buffers upon the commit! I'm not talking about SQLite's buffers, I'm talking about the file-system driver of the operating system. > As a "close" system call is performed! That still doesn't mean the pages are actually written to disk by the operating system, just that they're going to be marked as no longer in use and queued for writing. Nowhere in the POSIX spec for close() does it say the file needs to be sync'ed (especially in a blocking fashion) when close() is called. -j > "Jay A. Kreibich" wrote: On Fri, Apr 11, 2008 at 03:28:47PM +0200, Martin > Engelschalk scratched on the wall: > > Hello Donald, > > > > I don't think so: The journal files are not synchronized on SYNCHRONOUS > > = OFF, but they are still written, so transactions are still possible. > > Yes, but if I understand the SYNCHRONOUS=OFF setting correctly, there > is no reason the believe the journal files will ever make it out of the > operating system's file cache. Even if the OS does decide to spool > them off to disk, that's going to happen in an async manner. -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "'People who live in bamboo houses should not throw pandas.' Jesus said that." - "The Ninja", www.AskANinja.com, "Special Delivery 10: Pop!Tech 2006" ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any way to disable journaling & rollback?
On Fri, Apr 11, 2008 at 09:08:04AM -0700, Ken scratched on the wall: > Even with Synchronous = off > > Sqlite will flush its buffers upon the commit! I'm not talking about SQLite's buffers, I'm talking about the file-system driver of the operating system. > As a "close" system call is performed! That still doesn't mean the pages are actually written to disk by the operating system, just that they're going to be marked as no longer in use and queued for writing. Nowhere in the POSIX spec for close() does it say the file needs to be sync'ed (especially in a blocking fashion) when close() is called. -j > "Jay A. Kreibich" <[EMAIL PROTECTED]> wrote: On Fri, Apr 11, 2008 at > 03:28:47PM +0200, Martin Engelschalk scratched on the wall: > > Hello Donald, > > > > I don't think so: The journal files are not synchronized on SYNCHRONOUS > > = OFF, but they are still written, so transactions are still possible. > > Yes, but if I understand the SYNCHRONOUS=OFF setting correctly, there > is no reason the believe the journal files will ever make it out of the > operating system's file cache. Even if the OS does decide to spool > them off to disk, that's going to happen in an async manner. -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "'People who live in bamboo houses should not throw pandas.' Jesus said that." - "The Ninja", www.AskANinja.com, "Special Delivery 10: Pop!Tech 2006" ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any way to disable journaling & rollback?
Even with Synchronous = off Sqlite will flush its buffers upon the commit! As a "close" system call is performed! The next step is to Delete the file. :) (the commit point). "Jay A. Kreibich" <[EMAIL PROTECTED]> wrote: On Fri, Apr 11, 2008 at 03:28:47PM +0200, Martin Engelschalk scratched on the wall: > Hello Donald, > > I don't think so: The journal files are not synchronized on SYNCHRONOUS > = OFF, but they are still written, so transactions are still possible. Yes, but if I understand the SYNCHRONOUS=OFF setting correctly, there is no reason the believe the journal files will ever make it out of the operating system's file cache. Even if the OS does decide to spool them off to disk, that's going to happen in an async manner. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "'People who live in bamboo houses should not throw pandas.' Jesus said that." - "The Ninja", www.AskANinja.com, "Special Delivery 10: Pop!Tech 2006" ___ 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
Re: [sqlite] Any way to disable journaling & rollback?
Phil, Removing the journalling will certainly cause you lots of grief in the event of a "crash"... You could do the following, The write code (inserts) will queue incoming data into an "array/storage in memory etc..." When the first row is captured set a timer. When either the timer expires or you reach a row limit threshold, write the data to sqlite in a batched transaction. This way you get good performance and reliablity! But if you code crashes and you don't keep persistent what was in memory you'll loose that data. You'll probably need to do some tuning of the timer/row limits to get a balance between performance and potential data loss. HTH, Ken Phil Sherrod <[EMAIL PROTECTED]> wrote: > Do you know that the performance without doing anything special is unacceptable? If I do insertions of a test set of 2000 records using a BEGIN TRANSACTION/COMMIT around each one, the speed is 20 times slower than doing additions in a single transaction. I hacked the winSync routine and removed the call to FlushFileBuffers which forces Windows to write data from its cache to disk; this immediately sped up the run by a factor of 20 without making any other changes. In other words, removing the call of FlushFileBuffers for each transaction made my application run 20 times faster. A speed factor of 20 is significant. One solution is to batch up many insertions within the same transaction. The problem is that in my application insertions come in sporadically along with read accesses to the data that must be serviced quickly. So it is tricky to try to batch up insertions within transactions when I don't know how long it will be before another insertion arrives, and I must deal with a continuous flow of read accesses interleaved with the insertions. While transactions and rollback are a wonderful facility, I would like to see some option to turn them off when performance is the primary consideration. ___ 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
Re: [sqlite] Any way to disable journaling & rollback?
On Fri, Apr 11, 2008 at 03:28:47PM +0200, Martin Engelschalk scratched on the wall: > Hello Donald, > > I don't think so: The journal files are not synchronized on SYNCHRONOUS > = OFF, but they are still written, so transactions are still possible. Yes, but if I understand the SYNCHRONOUS=OFF setting correctly, there is no reason the believe the journal files will ever make it out of the operating system's file cache. Even if the OS does decide to spool them off to disk, that's going to happen in an async manner. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "'People who live in bamboo houses should not throw pandas.' Jesus said that." - "The Ninja", www.AskANinja.com, "Special Delivery 10: Pop!Tech 2006" ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any way to disable journaling & rollback?
Yes, transactions are not disabled, you're right. But would not setting SYNCHRONOUS off not give you about the same factor of 20 improvement as your removal of FlushFileBuffers -- without requiring a source change? As to what further speedup might result from truly disabling transactions, you wouldn't expect anywhere near another factor of 20, right? Perhaps only a small additional improvement? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Engelschalk Sent: Friday, April 11, 2008 9:29 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Any way to disable journaling & rollback? Hello Donald, I don't think so: The journal files are not synchronized on SYNCHRONOUS = OFF, but they are still written, so transactions are still possible. Martin Griggs, Donald wrote: > Regarding: " removing the call of FlushFileBuffers for each > transaction made my application run 20 times faster." > > Since you don't need the integrity protection that transactions > afford, would you not get the same performance gain using the standard > source and setting SYNCHRONOUS to zero? > > > > This email and any attachments have been scanned for known viruses using multiple scanners. We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. > This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- * Codeswift GmbH * Traunstr. 30 A-5026 Salzburg-Aigen Tel: +49 (0) 8662 / 494330 Mob: +49 (0) 171 / 4487687 Fax: +49 (0) 12120 / 204645 [EMAIL PROTECTED] www.codeswift.com / www.swiftcash.at Codeswift Professional IT Services GmbH Firmenbuch-Nr. FN 202820s UID-Nr. ATU 50576309 ___ 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
Re: [sqlite] Any way to disable journaling & rollback?
Hello Donald, I don't think so: The journal files are not synchronized on SYNCHRONOUS = OFF, but they are still written, so transactions are still possible. Martin Griggs, Donald wrote: > Regarding: " removing the call of FlushFileBuffers for each transaction > made my application run 20 times faster." > > Since you don't need the integrity protection that transactions afford, > would you not get the same performance gain using the standard source > and setting SYNCHRONOUS to zero? > > > > This email and any attachments have been scanned for known viruses using > multiple scanners. We believe that this email and any attachments are virus > free, however the recipient must take full responsibility for virus checking. > This email message is intended for the named recipient only. It may be > privileged and/or confidential. If you are not the named recipient of this > email please notify us immediately and do not copy it or use it for any > purpose, nor disclose its contents to any other person. > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- * Codeswift GmbH * Traunstr. 30 A-5026 Salzburg-Aigen Tel: +49 (0) 8662 / 494330 Mob: +49 (0) 171 / 4487687 Fax: +49 (0) 12120 / 204645 [EMAIL PROTECTED] www.codeswift.com / www.swiftcash.at Codeswift Professional IT Services GmbH Firmenbuch-Nr. FN 202820s UID-Nr. ATU 50576309 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any way to disable journaling & rollback?
Regarding: " removing the call of FlushFileBuffers for each transaction made my application run 20 times faster." Since you don't need the integrity protection that transactions afford, would you not get the same performance gain using the standard source and setting SYNCHRONOUS to zero? This email and any attachments have been scanned for known viruses using multiple scanners. We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any way to disable journaling & rollback?
> Do you know that the performance without doing anything special is unacceptable? If I do insertions of a test set of 2000 records using a BEGIN TRANSACTION/COMMIT around each one, the speed is 20 times slower than doing additions in a single transaction. I hacked the winSync routine and removed the call to FlushFileBuffers which forces Windows to write data from its cache to disk; this immediately sped up the run by a factor of 20 without making any other changes. In other words, removing the call of FlushFileBuffers for each transaction made my application run 20 times faster. A speed factor of 20 is significant. One solution is to batch up many insertions within the same transaction. The problem is that in my application insertions come in sporadically along with read accesses to the data that must be serviced quickly. So it is tricky to try to batch up insertions within transactions when I don't know how long it will be before another insertion arrives, and I must deal with a continuous flow of read accesses interleaved with the insertions. While transactions and rollback are a wonderful facility, I would like to see some option to turn them off when performance is the primary consideration. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any way to disable journaling & rollback?
Hi all, i have the same requirements. I don't need transactions at all and do not care if my databases become corrupt. However, i follow the versions of sqlite and do not want to change the code. Perhaps it is an idea to add something like "paragma disable_transactions" some time in the future? Martin Ken wrote: > Yes this can be Done. > > There are two approaches. >A. Modify the sqlite code. (ok for a one off but not very portable) >B. Write your own VFS driver. (portable and more as the author intended). > >http://www.sqlite.org/34to35.html > > > The best situation is if you are starting with an empty DB. Then you can > create it without journalling. If the process crashes in the middle, you'll > have to start over again. That shouldn't be an issue since you have all of > the original data. > > The other situation is if you have a database that has data. Then you need to > take a backup first. Then proceed with the load. If it crashes restore the > backup. > > HTH, > Ken > > Phil Sherrod <[EMAIL PROTECTED]> wrote: I have an application that requires > creating a database with about 50 > million records. Is there any way to turn off journaling and rollback > during the creation? I am willing to sacrifice reliability for speed in this > situation. > > > ___ > 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 > > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Any way to disable journaling & rollback?
Yes this can be Done. There are two approaches. A. Modify the sqlite code. (ok for a one off but not very portable) B. Write your own VFS driver. (portable and more as the author intended). http://www.sqlite.org/34to35.html The best situation is if you are starting with an empty DB. Then you can create it without journalling. If the process crashes in the middle, you'll have to start over again. That shouldn't be an issue since you have all of the original data. The other situation is if you have a database that has data. Then you need to take a backup first. Then proceed with the load. If it crashes restore the backup. HTH, Ken Phil Sherrod <[EMAIL PROTECTED]> wrote: I have an application that requires creating a database with about 50 million records. Is there any way to turn off journaling and rollback during the creation? I am willing to sacrifice reliability for speed in this situation. ___ 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
Re: [sqlite] Any way to disable journaling & rollback?
Phil Sherrod wrote: > I have an application that requires creating a database with about 50 > million records. Is there any way to turn off journaling and rollback > during the creation? I am willing to sacrifice reliability for speed in this > situation. > Do you know that the performance without doing anything special is unacceptable? Can you do trial runs with increasing fractions of the data to see? You might be pleasantly surprised. Just be sure to have large numbers of insertions in each transaction. Gerry ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
