Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 Transact-SQL (2005)
 Estimated Execution Plan

Author  Topic 

infodemers
Posting Yak Master

183 Posts

Posted - 2010-05-27 : 08:34:14
I ran the Estimated Execution Plan for a query.
I get the following results for two NODES (1 and 3)
My query run for hours....Can anyone tell me if this results is telling me what I should look at to make it faster?

Sort the Input

Physical Operation........................Sort
Logical operation................Distinct Sort
Estimated I/O Cost.....................4842.39
Estimated CPU Cost.....................72.6198
Estimated Number of Executions...............1
Estimated Operator Cost..............4915(49%)
Estimated Subtree Cost..................9933.9
Estimated Numbers of Rows..............2150020
Estimated Row Size......................1248 B
Node ID......................................1

Thanks in advance!

Kristen
Test

22859 Posts

Posted - 2010-05-27 : 09:46:21
Look at query plan to see what indexes are being used, and whether there are indexes you expected to be used which are not! or if there are places you could try adding an index.

As a very general rule / beginners guide:

Speed fastest-to-slowest is:

Index Seek
Index Scan
Table Seek
Table Scan

Also where you see an INDEX being used and the Index is the Clustered Index (which is usually the Primary Key too) and the columns in the Clustered Index are NOT the ones needed for the search, then although this seems to be an INDEX approach actually this is a last-ditch approach! because there is no other, and thus the Clustered Index is being used to check every single row in the table.

But your best way to make it faster is to post the query here and ask for advice. It will help, and get tyoua faster answer, if you post a script for the DDL - CREATE TABLE / COLUMNs and all CREATE INDEX. It will also help if can see the QUERY PLAN (in text format)

My money is on:

No / Wrong indexes
Function / Cast used in a JOIN
and possibly DISTINCT instead of careful JOINs to avoid duplicates in the first place.
Go to Top of Page

infodemers
Posting Yak Master

183 Posts

Posted - 2010-05-27 : 10:06:41
Thanks a lot Kristen!

I will take a look at the indexes first and that might do it.
I'll let you know.

Thanks again!

quote:
Originally posted by Kristen

Look at query plan to see what indexes are being used, and whether there are indexes you expected to be used which are not! or if there are places you could try adding an index.

As a very general rule / beginners guide:

Speed fastest-to-slowest is:

Index Seek
Index Scan
Table Seek
Table Scan

Also where you see an INDEX being used and the Index is the Clustered Index (which is usually the Primary Key too) and the columns in the Clustered Index are NOT the ones needed for the search, then although this seems to be an INDEX approach actually this is a last-ditch approach! because there is no other, and thus the Clustered Index is being used to check every single row in the table.

But your best way to make it faster is to post the query here and ask for advice. It will help, and get tyoua faster answer, if you post a script for the DDL - CREATE TABLE / COLUMNs and all CREATE INDEX. It will also help if can see the QUERY PLAN (in text format)

My money is on:

No / Wrong indexes
Function / Cast used in a JOIN
and possibly DISTINCT instead of careful JOINs to avoid duplicates in the first place.

Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2010-05-27 : 10:40:39
quote:
Originally posted by Kristen

Speed fastest-to-slowest is:

Index Seek
Index Scan
Table Seek
Table Scan


No such thing as a table seek. A table scan means a scan of a heap (a table without a clustered index)
If you meant 'clustered index seek' then it would typically be faster than an index scan, depending how much data is returned by the seek

quote:
Also where you see an INDEX being used and the Index is the Clustered Index (which is usually the Primary Key too) and the columns in the Clustered Index are NOT the ones needed for the search, then although this seems to be an INDEX approach actually this is a last-ditch approach! because there is no other, and thus the Clustered Index is being used to check every single row in the table.


That will appear as a clustered index scan.

For some insight into query plans, see Grant's book or my blog:
http://www.sqlservercentral.com/articles/books/65831/
http://sqlinthewild.co.za/index.php/2007/08/20/reading-execution-plans/

--
Gail Shaw
SQL Server MVP
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2010-05-27 : 11:47:58
Sorry, brain not in gear, thanks Gail.

I'll see if I can work Table Seek up into a world class performance tool that I can sell as a bolt on ... a bit like my famed "Come From" statement for Basic
Go to Top of Page

AndrewMurphy
Master Smack Fu Yak Hacker

2916 Posts

Posted - 2010-05-28 : 03:40:00
..."Come From" statement for Basic

Would that be related to the "Read my Mind" function that most database/programming languages seem not to have implemented?
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2010-05-28 : 05:06:10
Certainly not, that would require Dynamic SQL

Plus only one "data entry" form (with ESP ) ... how would we make any money?!

I did like the Elevators in "Hitch Hikers Guide to the Galaxy" which has ESP - they arrived on the floor you were on before you knew you needed one!
Go to Top of Page
   

- Advertisement -