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

Reply via email to