Do UDFs slow down Stored Proc execution?
From: John Kotuby (jkotuby_at_snet.net)
Date: 11/17/04
- Next message: JT: "Re: need help explaining patindex"
- Previous message: Joe Celko: "Re: Query Help"
- Next in thread: Adam Machanic: "Re: Do UDFs slow down Stored Proc execution?"
- Reply: Adam Machanic: "Re: Do UDFs slow down Stored Proc execution?"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 17 Nov 2004 12:11:08 -0500
I have a client/server checkwriter (VB/SQL Server 2000) that seem to be
running slowly upon commiting of the data back to the database. Originally
it was written without UDFs (in SQL 7). But along came SQL 2000 and I
decided to go with numerous UDFs to replace small procs that return a single
value, like a Date as a string, or an Error constant.
Admittedly the data commit procedure is quite involved, updating 14 tables
with accounting balances, check logging, detail (invoice#) logging and a
host of other things. I noticed that in a DB containing only 60,000
invoices, it takes 75 seconds to commit a check run of only 5 checks and 38
detail (invoice) lines. This is on a 2.2gh single processor box with 1gb of
ram and not much else running on it other than SQL Server. I believe that I
have created enough indexes to accomodate the task.
I have read that UDFs can slow performance. Which leads me to wonder why
Microsoft included them in SQL 2000. Is this actually true? Do they mess up
an optimization plan?
I tried creating a Work Load table from the SQL Profiler during a "check
run" to feed Index Optimizer , but it appears that the presence of the UDFs
also don't allow the Work Load to be used by the Optimizer.
What is the take on UDFs? Should they be avoided for the sake of
performance?
- Next message: JT: "Re: need help explaining patindex"
- Previous message: Joe Celko: "Re: Query Help"
- Next in thread: Adam Machanic: "Re: Do UDFs slow down Stored Proc execution?"
- Reply: Adam Machanic: "Re: Do UDFs slow down Stored Proc execution?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|