Big difference between Estimated and Actual Actual rows in execution Plan.

Question

Big difference between Estimated and Actual Actual rows in execution Plan.

Viewing 3 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Jo Pattyn SSC-Dedicated Points: 32571 More actions · Answer 1

Your query is too abstracted to give much information.

If it index seeks on object8 (alias) object name, there is an index on Object 8 Column7, Column 8 (or the other way around)

Is the index seek problematic ( zero rows?)

You have a function

There are a lot of nolocks

Are there any foreign keys / constraints defined that could help?

Is ? of the correct datatype (implicit vs explicit conversion)

Jeff Moden SSC Guru Points: 1004664 More actions · Answer 2

It's because <insert drumroll here>, it's an "Estimate". 😀

It's like asking someone how many wheels there are on their truck. Because of "statistics" on the subject and you've identified it as a "pickup truck", you might estimate that it has 4 wheels when it's actually a "dually" that has 6 wheels.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Jonathan AC Roberts SSCoach Points: 18407 More actions · Answer 3

Make sure all the columns on Object8 that your query references are either in the index key or the included columns, this will stop it doing a key lookup for each row. You could also rebuild the relevant index on that table to reduce any fragmentation.

Can you post the execution plan and the messages from running with SET STATISTICS IO, TIME ON?

I've got to add your table aliases seem designed to cause confusion.