Thanks Vladimir ... your input has made me look at my code again ...
Here is relevant portion of profsum.sql output ...
profsum
Lines taking more than 1% of the total time, each run separate
RUNID HSECSPCT OWNER UNIT_NAME LINE# TEXT
- --- --
Raj
I'm in :), so let's check what was the real issue, some more items
here...
Jamadagni, Rajendra wrote:
Thanks Vladimir ... your input has made me look at my code again ...
Here is relevant portion of profsum.sql output ...
profsum
Lines taking more than 1% of the total
Why do you think the profsum output is not right? at least it tells me that 83% of my
time is spent on the line that does substr() ... right?
msg_text is a clob, l_n is number you are right substr() was used because we
transfer only US ASCII data.
The point of pipelining was because in my
Raj
Jamadagni, Rajendra wrote:
Why do you think the profsum output is not right?
I did not say that profsum output is not right/correct. I said that it
does not show what's needed to be seen.
Just imagine to run SUBSTR() you call 1 internal function, to run utl_raw
PL/SQL engine has to do a lot
Read if you are interested ...
Finally I got some time and luckily the largest message to use with dbms_profiler. And
the results shocked me dbms_profiler showed me that instead of utl_raw, substr()
was the culprit. Remember my operation is character by character.
After some long thinking
Awesome, Raj!
And thank you for sharing this with us.
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Monday, October 27, 2003 4:29 PM
Read if you are interested ...
Finally I got some time and luckily the largest message to use with
Raj,
Jamadagni, Rajendra wrote:
Read if you are interested ...
Finally I got some time and luckily the largest message to use with dbms_profiler.
And the results shocked me dbms_profiler showed me that instead of utl_raw,
substr() was the culprit. Remember my operation is character by
