Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

INTERSECT 1 Expand / Collapse
Author
Message
Posted Tuesday, June 12, 2012 9:10 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 2:50 PM
Points: 3,796, Visits: 1,150
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.
Post #1314512
Posted Tuesday, June 12, 2012 11:43 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 4:33 PM
Points: 3,293, Visits: 1,977
Great question and dialogue. Thanks!
Post #1314611
Posted Wednesday, June 13, 2012 8:42 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 11:26 AM
Points: 8,718, Visits: 9,266
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
Post #1315184
Posted Monday, June 18, 2012 11:35 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, July 30, 2014 10:52 PM
Points: 483, Visits: 244
Hugo,

Thanks for the further explanation that supports the correct answer.
Post #1317472
Posted Monday, June 18, 2012 11:36 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, July 30, 2014 10:52 PM
Points: 483, Visits: 244
Nice question on the topic.

Thanks.
Post #1317474
Posted Tuesday, June 26, 2012 8:09 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, November 9, 2012 7:25 AM
Points: 298, Visits: 107
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!
Post #1321259
Posted Tuesday, June 26, 2012 2:58 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:20 PM
Points: 5,975, Visits: 8,236
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 MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Post #1321557
Posted Wednesday, June 27, 2012 2:03 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, November 9, 2012 7:25 AM
Points: 298, Visits: 107
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?
Post #1321732
Posted Wednesday, June 27, 2012 4:35 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:20 PM
Points: 5,975, Visits: 8,236
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 MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Post #1322210
Posted Thursday, June 28, 2012 6:44 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, November 9, 2012 7:25 AM
Points: 298, Visits: 107
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
Post #1322412
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse