Grant Fritchey (10/30/2013)
Your second query, the UNION, is getting a timeout from the optimizer. That means the plan is likely to be suboptimal. I'd suggest looking at ways to simplify the query. All those nested sub-selects within the queries with NOT IN might be better done as derived tables in an outer join looking for NULL values, but you'd need to test it to be sure. You also have an index scan in that query, but it looks like a pretty light part of the overall estimated cost, so it may not be anything to worry about. You also have some slight disparities on estimated rows, 7000+ in some cases where 900 are returned. Event taking into account the estimated number of executions (2), that still puts the number of rows off by ~ double. I don't think that's indicative of out of date or inaccurate statistics, but it might not hurt to look.
Hello, thx for reply..
The union is because there is sequencial feeding, 1-2 are before=done, 3 in progress on position , 4-7 will arrive... I will try thinking about little different solution, but I tried before , but now I have few more experience, so maybe it will be possible..
And problem with statistic we can dennied, because I updated all statistics every saturday. But maybe it will be possible that old ex.plan was after, when this table had lot of data and now I optimized with pk behind where clausule and etc... I will try also delete old ex.plan for this...
201310301300
201310301301
201310301302
201310301303
201310301304
201310301305
201310301306