September 16, 2010 at 9:51 am
Hey Jack,
Where did you and I have dinner last year? As I recall, it was close to the convention center.
Bob
__________________________________________________
Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills
September 16, 2010 at 11:37 am
The Dixie Flatline (9/16/2010)
Hey Jack,Where did you and I have dinner last year? As I recall, it was close to the convention center.
Bob
I think it was Macaroni Grill right across the street from the convention center.
So I guess this means you are returning this year. I think we need to have an SSC Threadizen meetup
-Jack
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
November 13, 2010 at 6:48 pm
Hey Bob! Man, I've gotta tell you it was a real pleasure to finally meet you in person. Thanks for the drink and the pork chops! 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
May 15, 2015 at 5:22 am
Jeff Moden (9/12/2010)
1. Hardware - Nill effect. Double the speed on the hardware on a 12 hour slug query and you still have a 6 hour slug query.
Are you sure on that Jeff,
Most hardware upgrades won't update all resources to the same extent and generally they are done to address a specific bottleneck.
Updating your storage throughput may mean your query is no longer constrained by that but may now suffer from a memory or CPU bottleneck instead.
As a result doubling the hardware speed is probably unlikely to give anywhere near a 50% reduction in query time.
Similarly changing from the query being constrained by one resource to a different one could surely impact which plan would be superior.
May 15, 2015 at 6:37 am
It usually does a pretty good job. Until the code gets more complex, that's where I usually need to spend some time on it to try and eliminate the bottlenecks.
Get your report proc working, start the optimizer routine on your dev or test server, and go do something else. It pops up in a little while with the top solutions based on the criteria you set (straight speed, memory utilization, etc...) that you could select from and export to production. That would be pretty cool.
If they would expose the optimizer as an API perhaps, and allow you to change what it was optimizing for, would you be able to tell it to optimize for a production configuration on other hardware? So you could say export a configuration from production then use that elsewhere to optimize against.
May 15, 2015 at 12:14 pm
Um... guys... did you look at when this thread started. Your advice is about 5 years too late 😉
__________________________________________________
Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills
May 16, 2015 at 10:27 pm
It's never too late for such advice.:w00t:
And I have to agree... if you can actually get a 50% query performance increase by changing hardware, you're pretty lucky.
Performance is in the code... where it's always been. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
May 17, 2015 at 10:44 am
Steve,
I can certainly envision a query that might benefit from having the best possible plan generated although I can't in my experience recall such a query, maybe because such option was not available.
Still, if the option was available, I would keep it in the back of my head as one of the many tools available to me, and I'd likely experiment with it.
I would even go so far as to say that if I decided to use it, I would first attempt to use it on the Production server (assuming there were no side-effects are detriments to production) and I would further like the option of being able to force the Optimizer to save the query plan by name so I could reference it later, on demand.
May 18, 2015 at 5:44 am
All these years later on and I still think that the early take that there is little value in spending so much resource on finding the best plan over one that is deemed good enough. Too many variables.
(No pun intended. For a change.)
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 18, 2015 at 12:39 pm
Jeff Moden (5/16/2015)
It's never too late for such advice.:w00t:And I have to agree... if you can actually get a 50% query performance increase by changing hardware, you're pretty lucky.
Performance is in the code... where it's always been. 🙂
+10
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
May 18, 2015 at 2:01 pm
What a great idea. I totally agree. Let me see if I can optimize it even more and then force sql to use my version.
May 18, 2015 at 2:26 pm
Iwas Bornready (5/18/2015)
What a great idea. I totally agree. Let me see if I can optimize it even more and then force sql to use my version.
Real DBAs hand code their execution plans and then enforce it using a plan guide. :hehe:
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 18, 2015 at 2:50 pm
Eric M Russell (5/18/2015)
Iwas Bornready (5/18/2015)
What a great idea. I totally agree. Let me see if I can optimize it even more and then force sql to use my version.Real DBAs hand code their execution plans and then enforce it using a plan guide. :hehe:
Easy enough with a good XML editor.....
__________________________________________________
Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills
Viewing 13 posts - 31 through 42 (of 42 total)
You must be logged in to reply to this topic. Login to reply