One-per-second sounds *very* slow - I think I was getting around 10 per second in my application, although usage patterns may account for the difference.
The main cause of the slowdown (IMHO) is inherent in ensuring that changes are written to physical disk. There are some pragmas that change the behavior of SQLITE in this respect, but performance improvements in this area are at some (finite) expense in data integrity. The only other solution for this might be fast disk drives or a solid-state disk. There is also the issue of attempting to synchronize writes to two (or more) different tasks. My own implementation was pretty primitive - it simply used the transaction controls in SQLITE. This approach worked, but I believe that a semaphore or other (external to the SQL language) signaling mechanism would be a more efficient means of synchronizing database access between tasks. *** Doug F. -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Christopher Taylor Sent: Monday, May 18, 2009 9:36 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Sqlite as a FIFO buffer? -------------------------------------------------- From: "Douglas E. Fajardo" <dfaja...@symark.com> Sent: Monday, May 18, 2009 12:25 PM To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>; "AllenFowler" <allen.fow...@yahoo.com> Subject: Re: [sqlite] Sqlite as a FIFO buffer? > One thing to watch out for - using SQLITE for a FIFO will have limited > throughput, because commits will have to be done after inserting or > removing each entry. This might not be an issue in some situations - I > have actually implemented a FIFO to communicate between two tasks where > the work-per-entry was significant, the transaction rate was low, and the > protection against accidental loss was paramount. > > *** Doug F. > > I have seen this. I have two other tables where the inserts can take up to 1 second to do. For my application this is acceptable. The events themselves are queued and there is enough idle time between jobs to catch up if needed. Is there a better way to do this? Chris _______________________________________________ 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
