Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
There is a trigger on a table for updates, inserts, and deletes, but the T-SQL create-script for the trigger contains only the following statement:
SET NOCOUNT ON
Is there a (significant) performance penalty for this trigger compared to no trigger? Would there be any (significant) performance penalty for a trigger with no statements (code), again compared to no trigger at all?
Without an in depth knowledge of what the optimiser is doing, or running a bunch of tests to check it’s hard to say. But then it’s hard to say how significant your idea of significant is either.
So to take each extreme, if you are doing thousands of updates a second then the trigger could cause a significant drop in performance… On the other hand running a few updates a minute you probably won’t notice at all. In either case the trigger will be compiled, and possibly optimised out of existence.
Myself I wouldn’t bother about performance unless performance was bothering me. If you think it is causing you issues, measure it, remove it and remeasure.
In a similar vein, I had a DBA suggest that I should replace Coalesce(xyz, 0) with Isnull(xyz, 0). The query wasn’t bothering me but the suggestion did, so I did some measurements and found that it was indeed 30% faster. But at 0.00000031 for each of the two coalesce callin in my query, I didn’t alter my query ;-