Re: Trigger performance

Alex,

My experience is:
You are going to loose >=25% of your processing time if you have a trigger. This is usually affordable, unless the table is bombarded with inserts. But if this the case, you would not store a value derived from another in the same table, would you? You would try to keep to a minimum the volume of data in a table. Besides, there are a lot of other factors that slow down performance, network f.e.

You can avoid triggers if you insert with destination=NULL, do your inserting and then update it with decode. And it is allright to do front-end checking in order to unload the server.

Regards,
Karen Abgarian.

Alex A. wrote:

> What is the performance impact of an insert trigger?
> I have a table
> ACTIONS(ACTION_TYPE, SOURCE, DESTINATION)
> and depending on ACTION_TYPE, DESTINATION may or may not
> be null. Is the cost of adding a trigger to enforce this
> significant (there are only about 10 action types)? If
> the overhead introduced by the trigger is significant,
> I'd rather rely on the front-end checking (although this
> is not the right thing to do...).
>
> Any advice?
>
> Thanks,
> Alex
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
Received on Tue Sep 14 1999 - 13:52:17 CDT