June 26, 2012 at 8:09 am
Nice question, thanks.
Prior to answering I would have done something like
SELECT DISTINCT x AS 'Intersect Chars with BIGINT'
FROM #A
INNER JOIN #B on #b.M = #a.x
A quick execution plan shows that the INTERSECT is ever so marginally more efficient too (in this case anyway), primarily because the Nested Loop step is a Left Semi Join, where the INNER JOIN has a slightly higher nested loop step cost.
Every day's a school day!
June 26, 2012 at 2:58 pm
chriscoates (6/26/2012)
Nice question, thanks.Prior to answering I would have done something like
SELECT DISTINCT x AS 'Intersect Chars with BIGINT'
FROM #A
INNER JOIN #B on #b.M = #a.x
A quick execution plan shows that the INTERSECT is ever so marginally more efficient too (in this case anyway), primarily because the Nested Loop step is a Left Semi Join, where the INNER JOIN has a slightly higher nested loop step cost.
Every day's a school day!
Note that they are only equivalent when the columns #a.x and #b.M are unique. If there is a primary key, unique constraint, or unique index involved, you can be sure that they are unique; otherwise you can't, so you can't just replace one with the other.
June 27, 2012 at 2:03 am
Perhaps we are at cross purposes Hugo, I meant tht the result set is the same, regardless of uniqueness. Of course if the values are not unique then there's a man-to-many relationship that I'm sure would make my query cost soar to determine the DISTINCT results, but the output would surely be the same?
Am I missing something else obvious here?
June 27, 2012 at 4:35 pm
chriscoates (6/27/2012)
Perhaps we are at cross purposes Hugo, I meant tht the result set is the same, regardless of uniqueness. Of course if the values are not unique then there's a man-to-many relationship that I'm sure would make my query cost soar to determine the DISTINCT results, but the output would surely be the same?Am I missing something else obvious here?
When comparing two queries for performance, the first thing you must consider is whether they are equivalent. Not just for one set of data, but for each possible set of data.
In the case of this question, the queries happen to produce the same result for the given data, but will give different results with other data, so they are not equivalent, and you cannot replace one with the other in a production system. If you add constraints to ensure that they are equivalent, the optimizer might (I didn't test this, and have no time for it either) well produce identical plans for the two queries. Without those constraints, it can't produce identical plans, since (depending on the data) it might have to return different results.
June 28, 2012 at 6:44 am
To quote this question, and the article it refers to:
INERSECT returns "those distinct values that are common between tables"
I have never seen a situation where:
SELECT DISTINCT a.x
FROM a
INNER JOIN b on a.x=b.m
would not return "those distinct values that are common between tables" either, regardless of the uniqueness of a.x or b.m in either query.
I agree that the execution may be completely different in either case.
Chris
June 28, 2012 at 2:38 pm
chriscoates (6/28/2012)
To quote this question, and the article it refers to:INERSECT returns "those distinct values that are common between tables"
I have never seen a situation where:
SELECT DISTINCT a.x
FROM a
INNER JOIN b on a.x=b.m
would not return "those distinct values that are common between tables" either, regardless of the uniqueness of a.x or b.m in either query.
I agree that the execution may be completely different in either case.
Chris
Chris, you are right. I only now notice that I first overlooked the DISTINCT in the query alternative that uses joins.. My apologies.
August 9, 2012 at 8:39 am
Good question!
January 8, 2013 at 6:47 am
Easy One..
--
Dineshbabu
Desire to learn new things..
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply