Alessandro Merolli <amero...@mwneo.com> wrote: > Most of the time, the statements requested are > grouped into a database transaction like this: > > BEGIN TRANSACTION; > INSERT INTO TBTEST (X,Y,Z) SELECT X,Y,Z FROM TBDATA JOIN ... ; > DELETE FROM TBTEST WHERE X NOT IN (SELECT ....); > UPDATE TBTEST SET Y=y WHERE X=x; > COMMIT TRANSACTION; > > I'm already considering all the issues that this kind of design > has: database concurrency, database locks, etc... but, this is not the > thing. > I'm experiencing a behavior that seams strange to me and I'd like > to check if anybody can give me some tips to minimize this: The COMMIT > statement consumes 50% or more of the time of the whole transaction; > for example: if the whole transaction costs 2000 ms, only the COMMIT > operation took 1500 ms.
Most likely, your transaction is small enough to be performed entirely within in-memory cache, without ever spilling to disk. Then, COMMIT has to actually write all the dirty pages to disk. Naturally, that's going to be the slowest part. Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
