I have a trigger on a table, which performs multiple operations. It is a business requirements that these operations happen (at least) at a predefined time interval from each other, so I plan to use the following:
WAITFOR DELAY '00:00:05'
I am wondering what (if any) performance considerations I should take into account when using the above statement, will it cause subsequent inserts or updates on the table to be blocked until the trigger has completed, or will the trigger run in the context of the current scope?
will it cause subsequent inserts or updates on the table to be blocked until the trigger has completed
Yes, yes it will. The entire body of a trigger is executed in the context of the transaction for the original insert, update or delete. (There's always a transaction, either one you create explicitly or one that SQL Server provides automatically and which is may automatically commit).
This is why the advice is to never put anything slow (or potentially slow1) inside a trigger - you're keeping the original transaction and any locks it has taken alive for longer.
Instead, I'd suggest, if at all possible to decouple your new activity from the original trigger - you could send a service broker message, or add a row to a table that a SQL Agent job reads to look for new work to do, or something else - just make sure it's something local to the same database and fast.
1Usually, this advice is given in the context of accessing external resources - which may be fast to access when they're there but can be exceptionally slow to report errors when something is broken.