|
Comments
|
|
Ok, so at the end you state that it's "a very expensive operation" - and then the video ends. What kind of message does that send to the people that watch this? To complete the message, why not drive home the concept that Cursors represent ROW Processing and that most row processing is expensive (and EVIL when it comes to performance). Follow that bombshell with at least a small plug for SET Processing - what it is and why it is soooooo much better for performance.
|
|
|
gr8
|
|
|
seems like there should be a summary at the end
|
|
|
This video appeared to end prematurely. It was doing great until then!
|
|
Sara Karasik on
7/31/2009
tells me absolutely nothing i didn't know before.
|
|
|
seems like it ends early. how about a little more explaination of what is happening in the actual execution plan? the select each time is from the temp table?
|
|
|
Where is the sequel? This one ends as a cliffhanger indicating how expensive the actual plan for this cursor turns out to be.
If a cursor is required (in my case a stored procedure is executed inside of the cursor loop) are there hints or changes that can be made to the SQL to make the operation more efficient?
|
|
John H Davis on
7/31/2009
I agree, it did not tell me anything I did not already know. Why not show a before and after with the code changed to not use cursors.
|
|
|
It should have been just a little bit longer to discuss the actual execution plan
|
|
|
Good, but ends abruptly and just when he gets to the point (cursors=bad) which should have then been elaborated upon.
|
|
|
Expensive, but what if anything can be done to cheapen it?
|
|
|
Short sharp to the point
|
|
|
The end was very abrupt could you please give some more information on why its expensive and why didnt it build a work table and select from there.
|
|
|
I'm sorry people were disappointed in the video. This one, like all the others I've created to date, was to define the constructs within the execution plan, not to show solutions to cursors or ways of tuning them. Those are all good ideas for videos in the future though.
|
|
|
I didn't understand why the actual execution query plan differed from the one originally presented.
|
|
|
When will the beer summit take place to expose the stimulus plan for row processing the kinder and gentler way?
|
|
|
Thanks for showing that Cursors are expensive, but no mention on useful and more efficient alternatives.
|
|
Steve Harris on
8/24/2009
Seems like the video was cut short. What was the actual execution doing individual select statements when the estimated plan thought it would use a query?
|
|
|
The estimated plan showed a single pass through the cursor. The actual plan tried to show all passes through the cursor.
|
|
|
As for my understanding of this video, estimated execution plan just shows that temp table is created.This is seen as one execution for the cursor, whereas in the actual execution plan we see the temp table operation is repeated as many times as the number of rows returned from the select query. No wonder CURSORS are expensive with regards to memory, just imagine doing it on a million row table..good work Grant, I hope I make it clear to everyone else here. Don't feel the video ended abruptly, as he already made the point. Thanks!!
|
|
|
Chris, thanks for the kind words, but I'm going to disagree with you just a bit. The video did end abruptly if you were counting on the video to show you three things, what happens in the execution plan of a cursor, why did it happen and what to do about it. I got about half way through those three things. I covered what happens and about half of why. I think most people want the rest of the explanation. I really need to get on the stick with more videos.
|
|
|
Not finished video, without conclusion and explanation why SELECT statements are repeated in actual Execution Plan.
|