> 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? 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
