On 02/04/2011 06:01 AM, Kevin Wojniak wrote: > 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.
Do you have a test program that we can use to reproduce this phenomenon? Dan. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
