From C to PL/SQL

The most dangerous assumptions are those that you are not aware of. We all know we should question assumptions and verify everything, but how can you question the assumptions you don’t even know you have?

C developers who move to PL/SQL development should constantly be aware that they are not in AT&T labs anymore. Of course, constant awareness is easier said than done, and Oracle keeps surprising.

It keeps surprising even after we learned that in Oracle, integers are not really integers, and are not faster than decimals. Unless they are binary_integers. Binary_integers sounds nice and comfortable, C developers love binary – after all C is just portable assembly. Don’t get your hopes up though – you won’t find binary shift operators in the language. If you ask your co-workers about the missing binary operations, you are in for a lecture. Database people have their own optimization methodologies, and they only worry about bits and bytes when they count IO operations.

How to recognize a C developer who now dabbles in PL/SQL? Ask him how many times will the following code print “… running very slow calculation …”:

create function expr return number
is
begin
dbms_output.putline('... running very slow calculation ...');
return 10;
end;

begin
for i in 1..expr() loop
insert into t values (i);
end loop;
end;

A C developer will say “ten times”, and will insist on “optimizing” the loop and write:

declare
e number;
begin
e:=expr();
for i in 1..e loop
insert into t values (i);
end loop;
end;

PL/SQL developers will know that loop boundaries are calculated once, when you first enter the loop. Therefore the line will be printed exactly once, and the second version is not faster than the first.

As they said in Pulp Fiction:
“It’s the little differences. I mean they got the same shit over there that they got here, but it’s just – it’s just there it’s a little different.”

***
Another identifying trait of former C developers is that they are forever interested in low level internals, and particularly memory management.
Lucky for me, Christo Kutrovsky published a paper about this exact topic. It is the perfect paper – crystal clear, gets into all the interesting and important details, no attempts to dumb down anything, and it even has practical conclusions.


One Comment on “From C to PL/SQL”

  1. Looping can be dangerous with PL/SQL, even an innocent SYSDATE call in a loop may cost something you never may be aware of;

    Cost of Function Call

    Especially after 10g PL/SQL compiler can change for example non-bulk loop operations into bulk operations automatically if it can. I think similar features with the PL/SQL compiler will be evolving, but I didn’t have the change yet to SQL trace and see how they are doing with 11gR1.


Leave a comment