The following seems to cause a statement journal to be used on every "replace into" statement:
> create table T (col1 integer primary key not null, col2 integer not null ); > begin transaction; > replace into T (col1, col2) values (1,2); > replace into T (col1, col2) values (3,4); > ... > commit transaction; This is causing a performance problem in my application, which seems to have been introduced when upgrading from 3.6.18 to 3.6.19. It appears that in check-in 3f40c142c8 to insert.c, we now call sqlite3MultiWrite to "ensure foreign key related processing takes place when rows are deleted from the database by REPLACE conflict handling". It seems like we are just assuming that we may hit a foreign key constraint when doing the replace, instead of actually checking to see if any foreign key constraints exist. I can make the problem go away by commenting out the sqlite3MultiWrite call, or by removing the "not null" constraint on col2. In reading http://www.sqlite.org/tempfiles.html, it sounds like a statement journal file should only be created for statements that might change multiple rows and which might abort. It should be possible for sqlite to determine that the above "replace into" would only affect one row, since it doesn't have any foreign key constraints pointing into it. Does this represent a bug in sqlite, or is it just perhaps being overly conservative? Thanks, Jeremy _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
