Viewing 15 posts - 20,206 through 20,220 (of 22,224 total)
I have to say, that's not a shape for an execution plan that I've seen before. Like the others have said, concentrate on the scans. You're missing JOIN predicates which...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 9, 2008 at 6:22 am
File groups, I'm working on. Several people have asked the same question. I'll post something as soon as I have a complete story.
Custom reporting, since these properties are collected just...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 9, 2008 at 5:45 am
As GSquared pointed out above, table variables work in a similar fashion. Statistics aren't maintained on them (except when there is a primary key) so the optimizer always assigns them...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 9, 2008 at 5:22 am
A fine idea. I'll have to try that. Thanks.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 9, 2008 at 5:17 am
Of course the next thing you should worry about is stacking all the fixed length, non-nullable fields at the front of the page... There's a lot of things you can...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 1:19 pm
ganatra.neha (6/6/2008)
That was bulls eye. You were rightThank you
I shall try and rewrite the queries and avoid the the multi-statement UDF
Thank you once again
Glad I could...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 12:51 pm
I don't see the attachment.
I'll bet you're working with a table valued function, probably a multi-statement function instead of an inline. Right?
If so, the optimizer doesn't and can't know what...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 11:38 am
You'll have to do this from outside TSQL. I've done it two ways. First, write an app in .NET that opens threads and makes DB calls. It works, but it's...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 9:30 am
Enormous topic. I'm just getting going with Reporting Services myself. Short answer, SQL Server Business Intelligence Development Studio. Long answer... This is the book I'm starting to read.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 9:05 am
OK. That makes sense. I'm also not surprised it works like that. Thanks for the input.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 8:48 am
Another guy just asked for something similar over in the Development forum. I had the same answer for him. I kind of thought it might be possible in CLR. Is...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 8:25 am
The performance increase is pretty small in most cases, but it is there. It really depends though, if the data is fixed length, you should use CHAR/NCHAR for it. If...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 7:57 am
Honestly, that's a tough one.
Best approach I can recommend is to establish a very tight discipline around your main production builds. They should only be done by a script that...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 7:51 am
Oh yeah, this is a major SQL Server tool if you can put it to work. Talk to Tom LaRock some time. He's gone way past where I am currently...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 7:12 am
That's what I mean when I say you have to learn how to work with the tool. I generally type 'SELECT * FROM' and then start building the FROM clause...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 6, 2008 at 7:09 am
Viewing 15 posts - 20,206 through 20,220 (of 22,224 total)