Re: java stored procedures fast, but slow when called as SQL function

ctcgag_at_hotmail.com wrote in message news:<20030410114747.506$Cn_at_newsreader.com>...

>
> There's no reason (other than sanity, perhaps) that the code that
> implements the JVM can't be intimately mingled with the code that
> implements the Oracle server stuff.

Sanity is a good one... :)

> My understanding is that Oracle itself
> exists in several "layers", wouldn't those also require the same amount of
> context switching as java does?
>

Those "layers" are not called repeatedly for every single piece of execution around. That is the main difference. Switching to a JVM for every row to retrieve a function value is about as inneficient in today's CPU architecture as one can get. But for example having a layer of software that does SQL-parsing, another that optimizes it, another that sets up execution paths and another that runs the path is perfectly OK. Ie, don't switch contexts for every row/column.

Nothing wrong with the layers bit.
Ogres have layers too. So do onions. And parfaits. :)

>
> Well, maybe parts of Oracle actively discourage it's use, but other
> parts of Oracle perhaps haven't gotten the message yet.

Neither should they. Where it's being used by Oracle it's perfectly OK. I never said Oracle *themselves* are discouraging the internal use of the stuff inside the DB.

> Hmmm...Do you think they are going to start de-implementing built-in
> java functionality?

No, not at all.

> I'd rather remove my eye with a rusty spoon than write
> graph-isomorph computation algorithms in PL/SQL, and having triggers
> call out to external java servers doesn't seem all that appealing, either.

Fair enough. I also doubt the average user out there has a need for a language inside the DB that can implement graph-isomorph computation algorithms. Call it a hunch...

Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam Received on Thu Apr 10 2003 - 18:44:25 CDT