Reputation: 47
update using bulk collect or normal merge ?
I am trying to check the performance of update by using bulk collect and normal merge. I see that the performance is better when we use simple merge in a anonymous block. When I use bulk collect, it takes more time.
If normal update (merge) is faster than bulk collect, then why oracle has introduced it? Where do we actually see the benefit of bulk collect?
declare
l_start integer;
l_end integer;
begin
l_start := dbms_utility.get_time;
merge into test111 t1
using test112 t2
on (t1.col1 = t2.col3)
when matched then update
set t1.col2 = t1.col2*5;
l_end := dbms_utility.get_time;
dbms_output.put_line(l_end - l_start);
end;
declare
type nt_test is table of test112.col3%TYPE;
nt_val nt_test := nt_test();
cursor c is select col3 from test112;
c_limit integer := 100;
l_start integer;
l_end integer;
begin
l_start := DBMS_UTILITY.get_time;
open c;
loop
fetch c
bulk collect into nt_val limit c_limit;
exit when nt_val.count = 0;
forall i in indices of nt_val
update test111 set col2 = col2/ 5
where col1 = nt_val(i);
commit;
end loop;
l_end := dbms_utility.get_time;
dbms_output.put_line(l_end - l_start);
end;
I get 0.797 sec in the merge query and 171.352 with bulk collect
Upvotes: 0
Views: 1197
Reputation: 21
If you can do it in SQL it will be always faster but even then 171.352 is very high value. So I did my test and I added an index on test111(col1) and with same pl/sql block it has completed in 0.20 secs.
Upvotes: 2
Reputation: 231661
If you can do it in SQL, it is almost always more efficient to do it in SQL. If you have to resort to PL/SQL because you're doing some processing that benefits from procedural code, doing a bulk collect
and a forall
will be more efficient than the old style row-by-row processing (though if you're using implicit cursors, recent versions of Oracle will be doing a bulk collect
automatically behind the scenes so the difference isn't as big as it was).
In your test, I'd expect the commit in the loop to account for most of the difference in runtime. Obviously, that is functionally different than the SQL solution.
Upvotes: 8