THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Rob Farley

- Owner/Principal with LobsterPot Solutions (a MS Gold Partner consulting firm), Microsoft Certified Master, Microsoft MVP (SQL Server), APS/PDW trainer and leader of the SQL User Group in Adelaide, Australia. Rob is a former director of PASS, and provides consulting and training courses around the world in SQL Server and BI topics.

Probe Residual when you have a Hash Match – a hidden cost in execution plans

Hi! - Great that you've found this page, but it's no longer here! You can find the content over at: http://blogs.lobsterpot.com.au/2011/03/22/probe-residual-when-you-have-a-hash-match-a-hidden-cost-in-execution-plans/

Published Tuesday, March 22, 2011 10:58 AM by Rob Farley

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Rob Farley said:

I could go on all day about APPLY – it really is an incredible part of T-SQL. It helps solves problems

April 12, 2011 7:30 PM
 

Rob Farley said:

My guys are great! When PASS started accepting abstract submissions for their Summit (in October this

May 6, 2011 12:05 AM
 

Paul White: Page Free Space said:

You probably already know that it’s important to be aware of data types when writing queries, and that

July 18, 2011 9:06 PM
 

Chris Adkin said:

Presumably the use of filter indexes might be another option for solving this problem ?

November 27, 2012 3:41 AM
 

Rob Farley said:

Yes - but this post is more designed for highlighting the issue. I figure that solving it is a standard exercise in query tuning, once you see the impact of the Residuality.

November 27, 2012 3:45 AM
 

Dave said:

The bitly link don't work no more!! :(

March 9, 2014 9:20 PM
 

Dave said:

March 9, 2014 9:21 PM
 

Rob Farley said:

Hmm... As I wrote over on that post, it's working for me...

March 10, 2014 1:14 AM
 

jeff said:

"You’ll see here that for each Product we find, we look up the Subcategory name for it." Isn't that backwards? Hover over a "Nested Loops (Inner Join)" operator: "For each row in the top (outer) input, scan the bottom (inner) input, and output matching rows."

September 3, 2015 12:43 PM
 

Rob Farley said:

Hi Jeff - yes, that's a typo. 4.5 years this post has been up, and no one's mentioned that typo before. Maybe you're my only reader?

September 3, 2015 5:15 PM
 

jeff said:

Your only reader? I doubt it - your posts are really interesting! (Digging the stuff on LQS.) Maybe I'm the most OCD... :)

September 15, 2015 11:40 AM
 

Rob Farley said:

You like the stuff on LQS? Cool! You can have a raise!

September 15, 2015 5:12 PM
 

Jeroen said:

Nice post! Thanks!

February 11, 2016 4:59 AM
 

Harper said:

The post is so interesting. But how about the Nested Loop? Could we need using APPLY operator to solved the residual predicate?

August 22, 2016 11:32 PM
 

Lokesh said:

Thanks Rob for such great blogs.Very interesting and well described.

September 7, 2017 12:40 PM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

Tags

No tags have been created or used yet.

News

News? Haven't you read my blog?

My Company


Can't find something?

Contact Me

IM: rob_farley@hotmail.com
Twitter: @rob_farley
Skype: rob_farley
E: rob_farley@hotmail.com

MVP (SQL Server)




Certifications








Adelaide SQL UG

Privacy Statement