On May 7, 2009, at 11:40 AM, Pavel Ivanov wrote: >> At the top of file memjournal.c there is a #define called >> "JOURNAL_CHUNKSIZE" >> that sets the size of the allocations used to store the in-memory >> journal. > > I was interested more in the way to do it without recompilation. > So there's no such way - that's ok for now, I can adapt myself to it. > >> In this case it will only matter if you have statements that affect >> more >> than one row that could hit a constraint. i.e. an UPDATE or an INSERT >> INTO >> ... SELECT statement. > > So, if I always do INSERT ... VALUES (), i.e. always insert only one > row by one statement, then this insert will be able to rollback > harmlessly even without journal?
Assuming it's a constraint failure that causes the rollback that is true (what else could it be?). The constraints are all checked before the database is modified. Dan. > Pavel > > On Thu, May 7, 2009 at 12:27 AM, Dan <[email protected]> wrote: >> >> On May 7, 2009, at 3:27 AM, Pavel Ivanov wrote: >> >>> Hi, all! >>> >>> Recently I've discovered that my application works faster if it uses >>> journal_mode = PERSIST instead of MEMORY. After running under >>> callgrind I've found that with journal_mode = MEMORY application >>> spends a lot of time inside malloc() which is called from >>> memjrnlWrite(). Is there a way to override this? I mean, I'd be >>> happy >>> to implement my own vfs for memory journal to avoid such intensive >>> use >>> of malloc(), but it seams that there's no way to do that. Am I wrong >>> and there is actually a way to do it? >> >> At the top of file memjournal.c there is a #define called >> "JOURNAL_CHUNKSIZE" >> that sets the size of the allocations used to store the in-memory >> journal. >> Currently it is defined to (just under) 1024. Maybe you could try >> setting >> it to a larger value and recompiling. >> >>> Now I want to add into application work with in-memory database. For >>> this kind of databases there's only 2 possible values for >>> journal_mode >>> - MEMORY and OFF. I'm afraid that with MEMORY I'll get the same >>> negative performance impact, so I'm leaning to OFF. But if I have >>> journal turned off, make insert into the table and it fails >>> because of >>> unique constraint will it be able to rollback this insert statement? >>> And more general: has journal any meaning at all when all my >>> transactions contain only one auto-committing statement? >> >> In this case it will only matter if you have statements that affect >> more >> than one row that could hit a constraint. i.e. an UPDATE or an INSERT >> INTO >> ... SELECT statement. >> >> Dan. >> >> _______________________________________________ >> sqlite-users mailing list >> [email protected] >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
