Well, an insert costs what it costs. You can sometimes reduce the cost by doing things like eliminating indexes, but it doesn't seem like that's an issue here. It would be great to see an actual plan generated from within Plan Explorer so we can see things like duration. My guess is that while that has a seemingly high I/O cost, the relative cost % is not a meaningful metric.
I have re run the query from with PE like you said. I didn't even know you could do this - so much more info available. I have attached the plan as requested....
Thanks, link text
Seems to me that most of the work is spent doing all those clustered index scans, which contribute to a high number, not the insert itself. Have you considered indexing a persisted computed column like UnsafeConditionsObserved + SuggestedSolution, and then a filtered index against computedcolumn > ''? Just one example that might avoid scanning PC_Core_UnsafeConditionsObserved (the benefit will depend on how many rows have a value in either of those columns).
Up to 50 attachments (including images) can be used with a maximum of 209.7 MB each and 209.7 MB total.
Answers and Comments
query plan x568
plan explorer upload x384
execution plan x105
poor performance x98
asked: May 05 at 08:32 AM
Seen: 109 times
Last Updated: May 05 at 08:35 PM
Same Query, Two Plans, One Stinks
Component running slow
Is there a better way to search for matches
Execution plan mystery
Any idea why the filter limiting to 5K instead of 320K rows is done at the end ?
A filter with the attached query causing slowness and performance issues
Trying to understand why partition elimination is happening in some plans, but not others
Slow query - I think my index is just making things worse :(
The query takes a long time to run, looking for options to try and get it to run faster based on this plan?
© 2013 SQL Sentry, Inc. All rights reserved.