Will using for loop decrease the performance

Question

Hi,
Will using for loop with a query decrease the performance.
for r_row in (select * from table) Loop
end loop.
This is done inside another for loop, most of the cases it returns only one value.
will it decrease the peformance of the procedure.
kindly advice.......
Regards,
Balu

Answer 1

user575682 wrote:
Will using for loop with a query decrease the performance.
for r_row in (select * from table) Loop
end loop.
This is done inside another for loop, most of the cases it returns only one value.
will it decrease the peformance of the procedure.Perhaps it is better to understand just what this PL/SQL loop construct does.
PL/SQL is two languages. It is PL (programming logic code) like Pascal or C or Java. You can use a 2nd language inside it called SQL. The PL engine is clever enough to recognise when the 2nd language is used. And it compiles all the stuff that is needed for the PL engine to call the SQL engine, pass data to the SQL engine and get data back, etc. (compare this with the complexity of using the SQL language in Pascal or C or Java).
So what does that loop do? The PL engine recognises the SQL SELECT statement. It creates an implicit cursor by calling the SQL engine to parse it (hopefully a soft parse) and then execute it.
As part of the PL loop, the PL engine now calls the SQL engine to fetch the data (rows) from the cursor. With 10g and later, the PL engine is smart enough to use implicit bulk processing.
Prior to 10g it used to fetch a row from the SQL engine, do the loop, fetch the next row, do the loop, etc. This means if there is a 1000 rows to fetch, it will call the SQL engine a 1000 times.
With 10g and later it will fetch a 100 rows, store that in an internal buffer and then do the loop a 100 times. With a 1000 rows to fetch, it now only requires 10 bulk fetches instead of a 1000 single row fetches.
These fetches require a context switch - as the PL engine has to step out and into the SQL engine and back, to fetch a row. This is an overhead and thus can become slow the more context switching there is.
And this is the basics for this loop (and most other cursor loops) construct in PL/SQL.
The ideal is to reduce the number of context switches. This is an overhead that can impact on performance.
What about using a loop within a loop. Also "bad". This uses the outer loop to fetch data. This data is then used to drive the fetch in the inner or nested loop. So the outside loop pulls data from the SQL engine into PL variables. The inside loop pushes that very same data back to the SQL engine.
Why? It would have been a lot faster no to pull and push that data between the loops using PL.
It will be a lot faster doing it via SQL only. Write both loops as a single SQL statement and have the SQL engine directly drive these loops itself. This is called a JOIN in SQL. And the SQL engine can do it not only faster, but it has some froody algorithms that can be used that are even faster than a nested loop process (called merge joins, hash joins, etc).
Bottom line. Maximise SQL. Minimise PL.*
Do as much of your data crunching in SQL as possible. SQL is the best and fastest "place" to process data. Not PL (or Pascal/C/Java).