December 26, 2013 at 6:13 pm
I hate to be the bearer of bad tidings during this holiday season, but this just came to my attention this morning.
Steven Willis, whom some of you may know by his many helpful forum posts, passed away back in October. When last I corresponded with him he had contracted a degenerative muscle disease (Polymyositis) and had taken an early retirement.
His last postings to the SSC forum were in Sep:
http://www.sqlservercentral.com/Forums/FindPost1497012.aspx
Even though I only knew him briefly, his contributions will be missed.
If anyone knows him and wants to pass on condolences to his family, you can PM me and I'll send you an email address that his daughter is watching.
Edit: Expired link fixed.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
December 27, 2013 at 11:06 am
dwain.c (12/26/2013)
I hate to be the bearer of bad tidings during this holiday season, but this just came to my attention this morning.Steven Willis, whom some of you may know by his many helpful forum posts, passed away back in October. When last I corresponded with him he had contracted a degenerative muscle disease (can't find the name of it at the moment) and had taken an early retirement.
His last postings to the SSC forum were in Sep:
Even though I only knew him briefly, his contributions will be missed.
If anyone knows him and wants to pass on condolences to his family, you can PM me and I'll send you an email address that his daughter is watching.
Thanks for the note.
December 27, 2013 at 12:23 pm
Hi everyone!!!
Please receive my best wishes for the holidays, although they are a little late. :blush:
I wish the best to you guys in the coming year and may the SQL Server force be with you all year long.
Tom,
Where were those pictures taken?
December 29, 2013 at 12:22 pm
EL Jerry (12/27/2013)
Tom,Where were those pictures taken?
The ones I posted about a week ago? In my garden, in Puerto del Carmen - that's 28°55'22,5?N 13°40'01,7?W, roughly. 🙂
Tom
December 30, 2013 at 1:44 am
Ok, after another frustrating thread of 'why do you want to remove that operator from the query, is it causing problems', the next article on the to-do list (after I finish deadlocks) is 'Premature Optimisation, or, measure twice, tune once'
Thoughts, comments, suggestions?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 30, 2013 at 2:32 am
dwain.c (12/26/2013)
I hate to be the bearer of bad tidings during this holiday season, but this just came to my attention this morning.Steven Willis, whom some of you may know by his many helpful forum posts, passed away back in October. When last I corresponded with him he had contracted a degenerative muscle disease (Polymyositis) and had taken an early retirement.
His last postings to the SSC forum were in Sep:
http://www.sqlservercentral.com/Forums/FindPost1497012.aspx
Even though I only knew him briefly, his contributions will be missed.
If anyone knows him and wants to pass on condolences to his family, you can PM me and I'll send you an email address that his daughter is watching.
Edit: Expired link fixed.
I'm very sorry to hear this. Steven was the mild-mannered poster, always helpful, never rattled.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
December 30, 2013 at 2:39 am
GilaMonster (12/30/2013)
Ok, after another frustrating thread of 'why do you want to remove that operator from the query, is it causing problems', the next article on the to-do list (after I finish deadlocks) is 'Premature Optimisation, or, measure twice, tune once'Thoughts, comments, suggestions?
Brilliant title, tricky subject. "Is that premature optimisation or are you just pleased to see me?"
Too often it's idleness, with PO offered as a poor excuse. I'd be happy to look it over if you wish, Gail.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
December 30, 2013 at 8:42 am
GilaMonster (12/30/2013)
Ok, after another frustrating thread of 'why do you want to remove that operator from the query, is it causing problems', the next article on the to-do list (after I finish deadlocks) is 'Premature Optimisation, or, measure twice, tune once'Thoughts, comments, suggestions?
I like the direction suggested by the proposed title - is there really a performance problem or are you just "tuning" the query as a knee-jerk response to seeing a scan in the execution plan or some similar shibboleth?
Jason Wolfkill
December 30, 2013 at 8:50 am
GilaMonster (12/30/2013)
Ok, after another frustrating thread of 'why do you want to remove that operator from the query, is it causing problems', the next article on the to-do list (after I finish deadlocks) is 'Premature Optimisation, or, measure twice, tune once'Thoughts, comments, suggestions?
I like it too. It suggests that we should tune based on measurement and testing. There are basics to put in place during design, but there's no way to anticipate all the ways people are going to use tables.
December 30, 2013 at 9:01 am
wolfkillj (12/30/2013)
is there really a performance problem or are you just "tuning" the query as a knee-jerk response to seeing a scan in the execution plan or some similar shibboleth?
Exactly.
I'm tired of all the threads 'help me get rid of joins', 'how do I force an index seek', 'which join type performs worst', etc, etc.
Title comes from http://en.wiktionary.org/wiki/measure_twice_and_cut_once
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 30, 2013 at 9:06 am
GilaMonster (12/30/2013)
wolfkillj (12/30/2013)
is there really a performance problem or are you just "tuning" the query as a knee-jerk response to seeing a scan in the execution plan or some similar shibboleth?Exactly.
I'm tired of all the threads 'help me get rid of joins', 'how do I force an index seek', 'which join type performs worst', etc, etc.
Title comes from http://en.wiktionary.org/wiki/measure_twice_and_cut_once
I like the title itself, too. I got the reference immediately - the "measure twice, cut once" maxim has saved me a good bit of aggravation in carpentry and woodworking projects.
Of course, "measure twice, cut once" really only refers to one of two possible error states - measuring too long/large and having to cut again to get the correct length/size. The other error state could probably be covered by the maxim, "measure twice, avoid a second trip to Home Depot."
Jason Wolfkill
December 30, 2013 at 9:09 am
wolfkillj (12/30/2013)
GilaMonster (12/30/2013)
wolfkillj (12/30/2013)
is there really a performance problem or are you just "tuning" the query as a knee-jerk response to seeing a scan in the execution plan or some similar shibboleth?Exactly.
I'm tired of all the threads 'help me get rid of joins', 'how do I force an index seek', 'which join type performs worst', etc, etc.
Title comes from http://en.wiktionary.org/wiki/measure_twice_and_cut_once
I like the title itself, too. I got the reference immediately - the "measure twice, cut once" maxim has saved me a good bit of aggravation in carpentry and woodworking projects.
Of course, "measure twice, cut once" really only refers to one of two possible error states - measuring too long/large and having to cut again to get the correct length/size. The other error state could probably be covered by the maxim, "measure twice, avoid a second trip to Home Depot."
For performance tuning, I would reword it as "Measure often, tune when needed."
December 30, 2013 at 9:11 am
Revenant (12/30/2013)
For performance tuning, I would reword it as "Measure often, tune when needed."
I was just thinking exactly that.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 30, 2013 at 9:17 am
wolfkillj (12/30/2013)
GilaMonster (12/30/2013)
wolfkillj (12/30/2013)
is there really a performance problem or are you just "tuning" the query as a knee-jerk response to seeing a scan in the execution plan or some similar shibboleth?Exactly.
I'm tired of all the threads 'help me get rid of joins', 'how do I force an index seek', 'which join type performs worst', etc, etc.
Title comes from http://en.wiktionary.org/wiki/measure_twice_and_cut_once
I like the title itself, too. I got the reference immediately - the "measure twice, cut once" maxim has saved me a good bit of aggravation in carpentry and woodworking projects.
Of course, "measure twice, cut once" really only refers to one of two possible error states - measuring too long/large and having to cut again to get the correct length/size. The other error state could probably be covered by the maxim, "measure twice, avoid a second trip to Home Depot."
The phrase "measure twice, cut once" let's you follow up with the phrase "You can't run the saw in reverse and put wood back on". I guess you can undo tuning efforts after they're done poorly, but there is a cost - just like the trip to Home Depot. Better and cheaper to do it right the first time.
Viewing 15 posts - 42,481 through 42,495 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply