Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Question about Indexes on #Temp Tables


Question about Indexes on #Temp Tables

Author
Message
tsceurman
tsceurman
Grasshopper
Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)

Group: General Forum Members
Points: 24 Visits: 1009
thomashohner (8/28/2014)
For the most part its being updated from the same 4 or 5 tables. On each Update. With different criteria on each one.

FROM #RESULTS r
INNER JOIN table1 t1 ON r.ID =t1id


I would consider a Primary Key on the column at least, assuming that it is unique in the temp table, more for ensuring results, but there may be performance benefits as well.

I'd be curious to see the code, because I'm sure there's stuff going on that could be combined or cut out.
Nadrek
Nadrek
Ten Centuries
Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)

Group: General Forum Members
Points: 1262 Visits: 2698
As others have said, you haven't given enough information, but you should first minimize the number of UPDATEs on bigger tables; if the FROM/JOIN clause is the same, you can use CASE in your SET lines, and spend a little more CPU on one pass through the table(s) rather than making multiple passes.

After that, you can experiment with indexes - the usual rules apply, include useful columns from the FROM and WHERE clauses, and of those, generally favor high cardinality as leftmost, etc.

Change where you build the index, see what happens!

On bigger #temp tables, if you're updating columns in the index, build it afterwards. Or rebuild it afterwards!

Use Profiler on the SQL:BatchCompleted event primarily using the CPU, Reads, Writes, and Duration columns; you want to see the aggregate effect on the entire batch, i.e. do the index(es) cost more than they benefit? You'll need to know if you're bottlenecked by CPU or Reads or Writes (most systems I see are IO bottlenecked, so I weight Reads and Writes much higher than CPU; exceptions exist, and all environments are different).
Ed Wagner
Ed Wagner
SSChampion
SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)

Group: General Forum Members
Points: 11870 Visits: 9801
The only way to be sure is to test. See what columns in your temp table are being used to perform the updates (hopefully a single column), then weigh the cost of creating an index on that column against the time you'll have in doing your updates. If you're using a single column for multiple updates in your 1400-line procedure, you'll likely benefit from indexing it. Again, testing it both ways is the only way to be sure.


Tally Tables - Performance Personified
String Splitting with True Performance
Best practices on how to ask questions
thomashohner
thomashohner
SSC-Addicted
SSC-Addicted (456 reputation)SSC-Addicted (456 reputation)SSC-Addicted (456 reputation)SSC-Addicted (456 reputation)SSC-Addicted (456 reputation)SSC-Addicted (456 reputation)SSC-Addicted (456 reputation)SSC-Addicted (456 reputation)

Group: General Forum Members
Points: 456 Visits: 2253
Thanks everyone for the suggestions. I also appoligize about the limited information. Its hard to post the real code because of my company and because its so large.

I will say yes it helped! Went from 5 seconds down to 1 second on my little db for run time.

***SQL born on date Spring 2013:-)
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search