Azure SQL
I am converting some TSQL Code and I have a number of table variable declaration. They are not performing as well as when they as on a physical device. I have read some unofficial sites that say that a temp table is the way to go. Do I have other options?
If you share your code with us we would help you better. Maybe the issue isn't only on table variables.
ASKER
I cannot share the code however I can describe it.
There is a table variable declared which takes an initial field of the type UNIQUEIDENTIFIER. Thereafter a lot of updates are run to fully populate the table. The reason for the many is that there is a lot of outer joins which use COALESCE to determine which is the active link within the ON part of the join. Breaking it down A little has improved the performace by 70%.
However having read around there is still some concern that DECLARE %TableName TABLE(...) is considered slower than CREATE TABLE @TABLENAME (...) which traditionally it has not been when using any CRUD activity.
There is a table variable declared which takes an initial field of the type UNIQUEIDENTIFIER. Thereafter a lot of updates are run to fully populate the table. The reason for the many is that there is a lot of outer joins which use COALESCE to determine which is the active link within the ON part of the join. Breaking it down A little has improved the performace by 70%.
However having read around there is still some concern that DECLARE %TableName TABLE(...) is considered slower than CREATE TABLE @TABLENAME (...) which traditionally it has not been when using any CRUD activity.
ASKER
Ignore previous slight changes where wrong symbols used.
I cannot share the code however I can describe it.
There is a table variable declared which takes an initial field of the type UNIQUEIDENTIFIER. Thereafter a lot of updates are run to fully populate the table. The reason for the many is that there is a lot of outer joins which use COALESCE to determine which is the active link within the ON part of the join. Breaking it down A little has improved the performace by 70%.
However having read around there is still some concern that DECLARE @TableName TABLE(...) is considered slower than CREATE TABLE #TABLENAME (...) which traditionally it has not been when using any CRUD activity.
I cannot share the code however I can describe it.
There is a table variable declared which takes an initial field of the type UNIQUEIDENTIFIER. Thereafter a lot of updates are run to fully populate the table. The reason for the many is that there is a lot of outer joins which use COALESCE to determine which is the active link within the ON part of the join. Breaking it down A little has improved the performace by 70%.
However having read around there is still some concern that DECLARE @TableName TABLE(...) is considered slower than CREATE TABLE #TABLENAME (...) which traditionally it has not been when using any CRUD activity.
A temporary table allows you to do the same operations you do with regular tables (index, truncate, ...). These kind of operations are not allowed in table variables and perhaps it's because of this that it's common to say that table variables are slower than temporary tables.
My recommendation is to use temporary tables everywhere you can (for example Functions only allows table variables) and create indexes if you are working with large data so you can increase the performance.
If you are working with a small set of data and you won't need to do more operations than a simple select then there's no performance difference between those two options.
My recommendation is to use temporary tables everywhere you can (for example Functions only allows table variables) and create indexes if you are working with large data so you can increase the performance.
If you are working with a small set of data and you won't need to do more operations than a simple select then there's no performance difference between those two options.
ASKER
I am not sure this answers my question. I realise that adding an index is an obvious performance hike but the problem is simply why is there a performance difference and what can I do to resolve it?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hmmm, I see. Not terribly impressed with MIcrosoft for producing a limited option with no obvious advantages to its alternative.
ASKER
While not an answer I had hoped for it is the right answer. Thanks for your help
Temp tables is always a great way to speed up query's. Do you have a example of a query you want to improve ?