On Feb 3, 2011, at 2:27 PM, Jim Wilcoxson wrote: > On Thu, Feb 3, 2011 at 5:07 PM, Kevin Wojniak <kain...@kainjow.com> wrote: > >> >> On Feb 3, 2011, at 11:41 AM, Petite Abeille wrote: >> >>> On Feb 3, 2011, at 6:53 PM, Kevin Wojniak wrote: >>> >>>> The trigger is ran once via sqlite3_exec(); >>> >>> Hmm... you mean the trigger is run every single time you perform an >> insert, no? >> >> Yes. I should say the trigger is created once via sqlite3_exec(). >> >>>> Any insight as to why the trigger is significantly slower? >> > > Perhaps SQLite is having to recompile the trigger SQL on every use, whereas > your update stmt is prepared. I tried triggers once, and they were slow for > me too. > > Jim > -- > HashBackup: easy onsite and offsite Unix backup > http://www.hashbackup.com
If that were the case that'd seem like a major design flaw. I created a timing profile using the trigger and without. On the version without, most of the time is spent all in sqlite, as expected. The one with triggers had a ton more time spent in the various kernel file system functions (hfs, I'm on Mac OS 10.6.6). So it seems like the triggers are creating significant more file access. I have all the inserts surrounded by BEGIN/END TRANSACTION, so I don't see why this would be doing any more necessary work. Kevin _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users