Re: about SYSDATE function

Jonathan Lewis wrote:
>
> Interesting, but the following is in the 8.1.7
> standard.sql as part of the package body:
>
> -- In stdspc.pls this was
> -- PRAGMA interface(c,sysdate,"pessdt");
> -- now we call the server directly
> function sysdate return date is
> d date;
> begin
> select sysdate into d from sys.dual;
> return d;
> end;
>
> And this is from a system that has just been upgraded
> to 8.1.7.1 - and I've just run;
>
> alter sessions set sql_trace true;
> declare
> m_date date;
> begin
> m_date := sysdate;
> end;
>
> and found
> SELECT SYSDATE FROM SYS.DUAL
>
> in the trace file.
>
> (It'll be nice when it is corrected - there is a webserver
> system I support where the most expensive statement
> is SELECT SYSDATE FROM DUAL, and the second
> is SELECT USER FROM DUAL).
>
> --
> Jonathan Lewis
> Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk
>
> Practical Oracle 8i: Building Efficient Databases
> Publishers: Addison-Wesley
>
> Reviews at: http://www.jlcomp.demon.co.uk/book_rev.html
>
> Connor McDonald wrote in message <3AC6EB9A.606E_at_yahoo.com>...
> >
> >Found this in the patch note for 8.1.7.1
> >
> >"This performance regression was introduced with the fix in Bug:616870.
> >With this fix calling SYSDATE from PL/SQL is much slower as SYSDATE
> >is obtained by selecting from DUAL.
> >This fix restores server side performance by allowing server side PLSQL
> >to use internal calls rather than selecting from DUAL."
> >

I'm in the same boat - if you've ever seen the table api's that are generated by Designer you'll know what I mean...Every ins/del/upd chucks in a row level trigger with who and when the change occurred...

ugh!

-- 
===========================================
Connor McDonald
http://www.oracledba.co.uk (mirrored at
http://www.oradba.freeserve.co.uk)

"Some days you're the pigeon, some days you're the statue"