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 12»»

Odd behaviour from computed columns in a left outer join Expand / Collapse
Author
Message
Posted Wednesday, August 29, 2012 12:52 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, December 1, 2014 8:26 AM
Points: 26, Visits: 290
I have the following query:

SELECT  CE.ID ,
CA.CustomerID,
CA.PostalCode
FROM DBXN.CommunicationEntry CE
LEFT OUTER JOIN ( SELECT A.ID ,
CA.CustomerID ,
A.PostalCode,
A.EnglishAddressLine1
FROM DBXN.Customer_Address AS CA
INNER JOIN DBXN.Address AS A ON CA.AddressID = A.ID
) AS CA ON CE.CustomerID = CA.CustomerID
WHERE CE.ID = 6298103

When I run this I get very good results, there's an index seek and a key lookup on the Customer_Address table, and an index seek on the Address table - all with very low estimated number of rows (between 1-3). Each have seek predicates coming from the joined column.

However, the second I introduce this additional column:

SELECT  CE.ID ,
CA.CustomerID,
CA.PostalCode,
CA.EnglishAddressLine1
FROM DBXN.CommunicationEntry CE
LEFT OUTER JOIN ( SELECT A.ID ,
CA.CustomerID ,
A.PostalCode,
A.EnglishAddressLine1
FROM DBXN.Customer_Address AS CA
INNER JOIN DBXN.Address AS A ON CA.AddressID = A.ID
) AS CA ON CE.CustomerID = CA.CustomerID
WHERE CE.ID = 6298103

...the query plan changes to a full index scan where the estimated number of rows includes every record in the table, and there are no predicates whatsoever used until further up stream when it hits a filter. By that time there's an estimated 82.5 million rows with an estimated data size of 21GB.

The EnglishAddressLine1 column is a computed column that takes several of the other fields in the Address table and builds a formatted address, there are several others like it for Line2/Line3, etc - but this is the simplest illustration of the problem.

Just wondering if anyone has any insight on why a computed column coming from a left outer join would cause this?


  Post Attachments 
NQ1.sqlplan (7 views, 34.64 KB)
NQ2.sqlplan (5 views, 406.77 KB)
Post #1351853
Posted Wednesday, August 29, 2012 3:18 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, December 17, 2014 5:10 PM
Points: 222, Visits: 1,027
Please post plans for both of the queries.


Alex Suprun
Post #1351932
Posted Thursday, August 30, 2012 10:46 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, December 1, 2014 8:26 AM
Points: 26, Visits: 290
Hey Alex,

I've added the .sqlplan files to the original post... Thanks for your response!
Post #1352365
Posted Thursday, August 30, 2012 1:04 PM


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: 2 days ago @ 1:17 PM
Points: 3,467, Visits: 1,840
Just a guess but you might consider looking at your indexes. You probably have an index that covers CE.ID, CA.CustomerID and CA.PostalCode but doesn't include CA.EnglishAddressLine1.

I did a quick test and I was able to include a computed column in an index. Both as part of the index and as an included column.


Kenneth Fisher
I strive to live in a world where a chicken can cross the road without being questioned about its motives.
--------------------------------------------------------------------------------
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Link to my Blog Post --> www.SQLStudies.com
Post #1352435
Posted Thursday, August 30, 2012 1:37 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, December 17, 2014 5:10 PM
Points: 222, Visits: 1,027
Kenneth.Fisher (8/30/2012)
Just a guess but you might consider looking at your indexes. You probably have an index that covers CE.ID, CA.CustomerID and CA.PostalCode but doesn't include CA.EnglishAddressLine1.

I did a quick test and I was able to include a computed column in an index. Both as part of the index and as an included column.
Unfortunately it's not the case here. The function is referencing columns from other tables.



Alex Suprun
Post #1352466
Posted Thursday, August 30, 2012 1:55 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Monday, December 15, 2014 2:26 PM
Points: 5,466, Visits: 7,647
Kevin,

Can you post the schema and indexes for the tables CommunicationEntry, Customer_Address, and Address please?



- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Post #1352476
Posted Thursday, August 30, 2012 2:17 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, December 1, 2014 8:26 AM
Points: 26, Visits: 290
It's also only one of twelve similar columns on the same table, and that table currently sits at 19.7 million rows. Even if we could index each of them, I'm not sure we would. This is a db in development at the moment, and it would probably make more sense to go another route - like calling the address formatting function on the A.ID on the left side of the join, or elsewhere.

What I'm really interested in though, is determining why the join predicate gets applied so differently in each of the scenarios.
Post #1352490
Posted Thursday, August 30, 2012 2:50 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, December 1, 2014 8:26 AM
Points: 26, Visits: 290
Hey Craig,

I'm not sure I could post them in a useful format, if you're looking to try and re-create the actual problem. There ends up being quite a few foreign key relations through those three tables.

I'll check with the powers that be, and see how much I can post here.
Post #1352504
Posted Thursday, August 30, 2012 3:02 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, December 17, 2014 5:10 PM
Points: 222, Visits: 1,027
There are more tables in the query than those 3.
To be able to re-create the issue these tables are needed as well:

[DBXN].StreetNumberSuffixLookup
[DBXN].StreetTypeLookup
[DBXN].StreetDirectionLookup
[DBXN].RouteServiceTypeLookup
[DBXN].DeliveryInstallationTypeLookup
[DBXN].CountryLookup
[DBXN].ProvinceLookup



Alex Suprun
Post #1352511
Posted Thursday, August 30, 2012 3:06 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Monday, December 15, 2014 2:26 PM
Points: 5,466, Visits: 7,647
Kevin Dahl (8/30/2012)
Hey Craig,

I'm not sure I could post them in a useful format, if you're looking to try and re-create the actual problem. There ends up being quite a few foreign key relations through those three tables.

I'll check with the powers that be, and see how much I can post here.


I'm not looking to recreate the issue, I won't have your data disparity and other assundry bits to do that. What I'm looking to do is be able to analyze the indexes available, what's being ignored and what else it could use, things like that. With an understanding of the clustered vs. non-clustered we can offer you an alternative version of the same logic that will work with what you've already got built... hopefully.



- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Post #1352514
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse