June 11, 2014 at 6:54 am
Long story short, we have a query that joins column A int which is an int onto column B with contains only int's but was created as a varchar and can't be changed to an int at the moment.
casting column a as a varchar in the ON of the join to left join seems to void the index altogether and the query just runs for every.
We are talking a few hundred million rows of data in each table.
temp solution is select into a #Hash table as correct data type and index then use the #Hash table in the join.
Wondering if anyone has come across this before and has a good solution? aware the obvious answer is change the model for the right data type but that's a call i can't make and isn't going to happen.
Been googling but can't find a solution.
cheers
June 11, 2014 at 7:00 am
Add a computed persisted int column, add index and join on that?
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
June 11, 2014 at 7:05 am
CREATE TABLE #temp (colint INT, colvarchar VARCHAR(10), colcomputed AS CAST(colvarchar AS INT))
INSERT INTO #temp (colint, colvarchar) SELECT 1, '10'
SELECT * FROM #temp
CREATE INDEX ix_colcomputed ON #temp (colcomputed)
SELECT colcomputed FROM #temp WHERE colcomputed = 10
Heh Phil you're too quick mate!
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
June 11, 2014 at 7:16 am
Indexed view - or is that nuts?
June 11, 2014 at 7:23 am
ChrisM@Work (6/11/2014)
CREATE TABLE #temp (colint INT, colvarchar VARCHAR(10), colcomputed AS CAST(colvarchar AS INT))
INSERT INTO #temp (colint, colvarchar) SELECT 1, '10'
SELECT * FROM #temp
CREATE INDEX ix_colcomputed ON #temp (colcomputed)
SELECT colcomputed FROM #temp WHERE colcomputed = 10
Heh Phil you're too quick mate!
I've never faced this problem at work (yet), but this is a very elegant solution. Not sure about performance, but nice indeed.
June 11, 2014 at 7:35 am
sql-lover (6/11/2014)
ChrisM@Work (6/11/2014)
CREATE TABLE #temp (colint INT, colvarchar VARCHAR(10), colcomputed AS CAST(colvarchar AS INT))
INSERT INTO #temp (colint, colvarchar) SELECT 1, '10'
SELECT * FROM #temp
CREATE INDEX ix_colcomputed ON #temp (colcomputed)
SELECT colcomputed FROM #temp WHERE colcomputed = 10
Heh Phil you're too quick mate!
I've never faced this problem at work (yet), but this is a very elegant solution. Not sure about performance, but nice indeed.
The plan shows an index seek 😉
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
June 11, 2014 at 7:56 am
ChrisM@Work (6/11/2014)
CREATE TABLE #temp (colint INT, colvarchar VARCHAR(10), colcomputed AS CAST(colvarchar AS INT))
INSERT INTO #temp (colint, colvarchar) SELECT 1, '10'
SELECT * FROM #temp
CREATE INDEX ix_colcomputed ON #temp (colcomputed)
SELECT colcomputed FROM #temp WHERE colcomputed = 10
Heh Phil you're too quick mate!
Haha. I provided only words, you provided the nuts & bolts!
But wouldn't persisted be better for such a large amount of data?
create table #temp
(
colint int
,colvarchar varchar(10)
,colcomputed as cast(colvarchar as int) persisted
)
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply