|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: 2 days ago @ 9:19 AM
Points: 288,
Visits: 1,910
|
|
Jeff,
With runaway generation of rows I do not mean these rows end up in the result or are part of additional processing by the consuming parts of the query. But that rows are generated before the TOP operator takes effect when dealing with parallel execution plans. Not always, but frequent enaugh to cause issues of unpredictable large slowdowns. The processing is in the generation of the rows itself for large sets and not anything that depends on the rows that come out of the top operator.
It is a bug obviously and one that the connect issue can use an extra votes for :)
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 7:18 AM
Points: 33,112,
Visits: 27,038
|
|
Wow! I just read Paul's article. He really does do a nice job explaining some of these things.
To summarize, TOP apparently doesn't fix things for 2008 and above. You need to add OPTION(MAXDOP 1) to really get it to behave properly. That's ok because it still screams.
--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."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|