SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Optimizing Cursor Performance


Optimizing Cursor Performance

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: Administrators
Points: 62799 Visits: 19111

Apologies for this. I have removed the article. If links are broken, that it why.



Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
tho.pfaff
tho.pfaff
Grasshopper
Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)

Group: General Forum Members
Points: 10 Visits: 6
hi @all,

i want to know a bit more about cursors and the technical way they are realized. my understanding is, that cursors are pointers on a result-set within the ram. the result-set is small (comparing to the table the rows are from) and the sql which perform the result-set is executed only one time (i hope :o) ), right?
So what we have is a small result-set within a location the cpu has the fastest way to grab rows from this result-set.
why should this cursors (used in for loops) not be more efficient than ordinary sql-queries (in for loops)?

ordinary queries grap the rows from the hard-disk, where the cpu needs more time to grap them. and erery time the sql-query is executed the a full table-scan must be performed to find the row.

abstract:
cursors (used in for loops):
- sql-query to get the result-set is executed one time, to make a result set (in the initialsation-part of procedure)
- one small result-set
- fastest way for a cpu to grap the data, because they are in the ram

ordinary queries (used in for loops):
- executed to get on row per query
- in every execution the whole table has to be scaned to get one row, so there is no result-set to crawl over
- no fast way for the cpu to grap the data, because data is on harddrive

what du you think about what my understanding of cursors is. am i right?
please let me know.

cheers tommy
Lynn Pettis
Lynn Pettis
SSC-Dedicated
SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)

Group: General Forum Members
Points: 39495 Visits: 38553
You should know that wether you are using cursors or a while loop it is still RBAR (a Modenism for Row By Agonizing Row) processing. In almost all cases, converting cursor-based solutions to set-based solutions will result in improved performance and scalability of your code.

Cool
Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86380 Visits: 41098
tho.pfaff (11/21/2009)
hi @all,

i want to know a bit more about cursors and the technical way they are realized. my understanding is, that cursors are pointers on a result-set within the ram. the result-set is small (comparing to the table the rows are from) and the sql which perform the result-set is executed only one time (i hope :o) ), right?
So what we have is a small result-set within a location the cpu has the fastest way to grab rows from this result-set.
why should this cursors (used in for loops) not be more efficient than ordinary sql-queries (in for loops)?

ordinary queries grap the rows from the hard-disk, where the cpu needs more time to grap them. and erery time the sql-query is executed the a full table-scan must be performed to find the row.

abstract:
cursors (used in for loops):
- sql-query to get the result-set is executed one time, to make a result set (in the initialsation-part of procedure)
- one small result-set
- fastest way for a cpu to grap the data, because they are in the ram

ordinary queries (used in for loops):
- executed to get on row per query
- in every execution the whole table has to be scaned to get one row, so there is no result-set to crawl over
- no fast way for the cpu to grap the data, because data is on harddrive

what du you think about what my understanding of cursors is. am i right?
please let me know.

cheers tommy


I'm not sure who wrote that for you but it's mostly full of hooie... not all cursors are in ram just like not all non cursors are on disk.

Baiscally, cursors will always be slower than "Set Based" queries because cursors overcome and overwhelm the "natural" way that SQL Server operates.

With only 1 exception in 10,000, you should simply avoid cursors.

--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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Bru Medishetty
Bru Medishetty
SSCrazy
SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)

Group: General Forum Members
Points: 2516 Visits: 1950
tho.pfaff (11/21/2009)
ordinary queries grap the rows from the hard-disk, where the cpu needs more time to grap them. and erery time the sql-query is executed the a full table-scan must be performed to find the row.

It is not always true that ordinary queries fetches the rows from hard disk.

Regarding full table scan must be performed to find a row, that would be true if the company has a policy of no indexes and would never use an index ....:-) :-).

Your assumption is wrong Tommy, a full table scan happens when there are no indexes and can be avoided by having appropriate indexes..


Bru Medishetty

Blog -- LearnSQLWithBru

Join on Facebook Page Facebook.com\LearnSQLWithBru

Twitter -- BruMedishetty
DCPeterson
DCPeterson
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1567 Visits: 432
Bru Medishetty (11/22/2009)
tho.pfaff (11/21/2009)
ordinary queries grap the rows from the hard-disk, where the cpu needs more time to grap them. and erery time the sql-query is executed the a full table-scan must be performed to find the row.

It is not always true that ordinary queries fetches the rows from hard disk.

Regarding full table scan must be performed to find a row, that would be true if the company has a policy of no indexes and would never use an index ....:-) :-).

Your assumption is wrong Tommy, a full table scan happens when there are no indexes and can be avoided by having appropriate indexes..


What you said is true, but it seems to me that the question wasn't between a set-based query and cursor, but between a query in a for loop thus making it a RBAR operation rather than set-based.

The question seems to spring from a commonly held belief that if you need a RBAR operation (you almost never do) you are better off "rolling your own" cursors by using a loop that by using a cursor. My testing of this has proven (to me) that if you really need RBAR operation, you are likely better off using a real cursor as opposed to "rolling your own."

/*****************

If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek



*****************/
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86380 Visits: 41098
I agree with that whole heartedly, DC. I've found that a well written cursor will frequently beat a home grown While Loop just as you said. I'll also add that I think of While Loops as nothing more than "home grown cursors" and have resorted to calling them "cursors" even though that's probably a bit confusing to most. Based on that, allow me to correct what I said in the post previous to this one just to be clear... there are exceptions to every rule but all forms of RBAR (not just cursors) should be avoided if possible. I'll also add that, given a little thought, it's usually possible to avoid them without resorting to just another form of RBAR.

--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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search