|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 1:51 PM
Points: 24,
Visits: 235
|
|
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?
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Wednesday, May 01, 2013 3:15 PM
Points: 160,
Visits: 802
|
|
Please post plans for both of the queries.
Alex Suprun
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 1:51 PM
Points: 24,
Visits: 235
|
|
Hey Alex,
I've added the .sqlplan files to the original post... Thanks for your response!
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Thursday, May 09, 2013 8:31 AM
Points: 3,367,
Visits: 1,563
|
|
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
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Wednesday, May 01, 2013 3:15 PM
Points: 160,
Visits: 802
|
|
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
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Today @ 4:47 AM
Points: 5,672,
Visits: 6,115
|
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 1:51 PM
Points: 24,
Visits: 235
|
|
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.
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 1:51 PM
Points: 24,
Visits: 235
|
|
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.
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Wednesday, May 01, 2013 3:15 PM
Points: 160,
Visits: 802
|
|
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
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Today @ 4:47 AM
Points: 5,672,
Visits: 6,115
|
|
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
|
|
|
|