SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


INTERSECT 1


INTERSECT 1

Author
Message
EL Jerry
EL Jerry
SSCertifiable
SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)

Group: General Forum Members
Points: 5103 Visits: 1346
Really nice question. Thanks, Ron.

Hugo, thank you for the additional explanation, too. I would have not been able to understand it just by reading BOL.

"El" Jerry.

"El" Jerry.

"A watt of Ottawa" - Gerardo Galvan

To better understand your help request, please follow these best practices.
Ken Wymore
Ken Wymore
SSCrazy Eights
SSCrazy Eights (9.6K reputation)SSCrazy Eights (9.6K reputation)SSCrazy Eights (9.6K reputation)SSCrazy Eights (9.6K reputation)SSCrazy Eights (9.6K reputation)SSCrazy Eights (9.6K reputation)SSCrazy Eights (9.6K reputation)SSCrazy Eights (9.6K reputation)

Group: General Forum Members
Points: 9612 Visits: 2470
Great question and dialogue. Thanks!
Tom Thomson
Tom Thomson
SSC Guru
SSC Guru (50K reputation)SSC Guru (50K reputation)SSC Guru (50K reputation)SSC Guru (50K reputation)SSC Guru (50K reputation)SSC Guru (50K reputation)SSC Guru (50K reputation)SSC Guru (50K reputation)

Group: General Forum Members
Points: 50684 Visits: 13159
Nice tidy question, that brings up two importan fundamentals:
(1) intersection returns distinct values not duplicates
(2) equality tests do implicit conversion where needed, from lower precedence type to higher.

Tom

zymos
zymos
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1104 Visits: 263
Hugo,

Thanks for the further explanation that supports the correct answer.
zymos
zymos
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1104 Visits: 263
Nice question on the topic.

Thanks.
chriscoates
chriscoates
Old Hand
Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)

Group: General Forum Members
Points: 388 Visits: 110
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!
Hugo Kornelis
Hugo Kornelis
SSC-Dedicated
SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)

Group: General Forum Members
Points: 34342 Visits: 13119
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.


Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
chriscoates
chriscoates
Old Hand
Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)

Group: General Forum Members
Points: 388 Visits: 110
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?
Hugo Kornelis
Hugo Kornelis
SSC-Dedicated
SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)SSC-Dedicated (34K reputation)

Group: General Forum Members
Points: 34342 Visits: 13119
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.


Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
chriscoates
chriscoates
Old Hand
Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)Old Hand (388 reputation)

Group: General Forum Members
Points: 388 Visits: 110
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
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum








































































































































































SQLServerCentral


Search