Estimated row count vs actual row count

Im attempting to debug a statement written for reporting by our former BI analyst.

He wasn't particularly well versed in SQL, so a lot of his scripting uses unneeded case statements and joins against string operations.

I realize that there is a lot of that going on in this query, and i intend to address it.

This is only an issue when adding the filter against the fsalesacc. Without that filter, the query runs in about 2 seconds. With it, a little under 20 minutes.

My real quesion is, why is it that the estimated row count is so out of line if my statistics are updated and have little to no fragmentation on my indexes?

Also, is there a workaround that doesn involve using a temp table or a loopback openquery to force the query to ignore the estimated plan?

Plan.pesession (19.3 kB)
avatar image By Jmann84 1 asked Mar 15, 2016 at 09:57 PM
more ▼
(comments are locked)
10|10000 characters needed characters left

0 answers: sort voted first
Be the first one to answer this question
toggle preview:

Up to 50 attachments (including images) can be used with a maximum of 209.7 MB each and 209.7 MB total.

Follow this question

Topics:

x641
x166
x1

asked: Mar 15, 2016 at 09:57 PM

Seen: 343 times

Last Updated: Mar 15, 2016 at 09:57 PM