On Apr 11, 2005 5:13 PM, Andrew Piskorski <[EMAIL PROTECTED]> wrote: > Why do you want to do this with SQLite, rather than something like > PostgreSQL?
Yes, that is the alternative I consider. I would expect better performance and less configuration issues with an embedded database. Basically I have two applications: one has realtime constraints, but it would only write to the database. This writing may actually be defered to the second process, with a buffer in between. The second application does batch processing on the data. So I have no concurrent operations going on. What I was testing so far was getting the data into the database. > Do you have some hard constraint > that requires an embedded in-process database library like SQLite, > rather than a client-server RDBMS? No, but I am just trying to be lazy :-) > I suspect it's not your total transaction load that's a problem, it's > simply that SQLite doesn't support the concurrency you need. I think my current problem is that I use just one thread. So the latency introduced by fsync() after every single transaction is my problem. Using a client/server database is not going to make that any easier. Grouping transaction would be one solution, using concurrency the other, I think. Thomas
