Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Question about Indexes on #Temp Tables Expand / Collapse
Author
Message
Posted Friday, August 29, 2014 6:26 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, September 11, 2014 8:59 AM
Points: 19, Visits: 595
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.
Post #1608565
Posted Tuesday, September 2, 2014 10:05 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 11:09 AM
Points: 869, Visits: 2,399
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).
Post #1609680
Posted Tuesday, September 2, 2014 10:34 AM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 11:20 AM
Points: 4,316, Visits: 3,358
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
Post #1609696
Posted Tuesday, September 2, 2014 10:47 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 11:17 AM
Points: 169, Visits: 988
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
Post #1609703
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse