Performance comparison between using sql and pl/sql for same purpose

Question

Hi All,
I have to do some huge inserts into a table from some other tables. I have 2 option:
Option 1
======
a. Declare a cusor for a query involving all source tables, this will return the data to be populated into target
b. Use a cursor for loop to loop through all the records in the cursor
c. for each iteration of the loop, populate target columns, do any calculations/function calls required to populate derived columns, and then insert the resulting record into target table
Option 2
======
Just write a big single "Insert Into ..... Select ..." statement, doing alll calculations/funtion calls in the select statement generating the source data.
Now my question is ; which option is fast? and why. This operation is performace critical so I need the option which will run faster. Can anybody help???
Thanks in Advance.

Answer 1

user9314072 wrote:
while the above comments are vaild, you should concider maintainability in you code. Even if you can write the sql it might be the code becomes complex making tuning very dificult, and derade performance.Beg to differ on that. Regardless of complexity of code, SQL is always faster than PL/SQL when dealing with SQL data. The reason for that is that PL/SQL still needs to use SQL anyway for row retrieval, and in addition it needs to copy row data from the buffer cache into the PL/SQL PGA. This is an overhead that does not exist in SQL.
So if you are processing a 100 million rows with a complex 100 line SQL statement, versus a 100 million rows 100 line PL/SQL procedure, SQL will always be faster.
It is a trade off, my experiance is large SQL's 100's lines long become hard to manage. You need to ask yourself why there are 100's of line of SQL. This points to an underlying problem. A flaky data model is very likely the cause. Or not using SQL correctly. Many times a 100 line SQL can be changed to a 10 liner by introducing different logic that solves the exact same problem easier and faster (e.g. using analytical SQL, thinking "+out-of-the-box+").
Also, 100's of line of SQL points to a performance issue always. And it does not matter where you move this code logic to PL/SQL or Java or elsewhere, the performance problem will remain. Moving the problem from SQL to PL/SQL or Java does not reduce the number of rows to process, or make a significant change in the number of CPU instructions to be executed. And there's the above overhead mentioned - pulling SQL data into a client memory segment for processing (an overhead that does not exist using SQL).
So how do you address this then? Assuming the data model is correct, then there are 2 primary methods to address the 100's of SQL lines and its associated performance problem.
Modularise the SQL. Make the 100's of lines easier to maintain and understand. This can be done using VIEWS and the SQL WITH clause.
As for the associated performance issue - materialised views comes to mind as an excellent method to address this type of problem.
my advice is keep things simple, because soon or later you will need to change the code.I'm all for that - but introducing more moving parts like PL/SQL or Java and ref cursors and bulk fetching and so on.. how does that reduce complexity?
SQL is the first and best place to solve row crunching problems. Do not be fooled into thinking that you can achieve that same performance using PL/SQL or Java.