Re: [HACKERS] SQLJ
От | Constantin Teodorescu |
---|---|
Тема | Re: [HACKERS] SQLJ |
Дата | |
Msg-id | 3690D40C.A4D4F624@flex.ro обсуждение исходный текст |
Ответ на | SQLJ (Dan Gowin <DGowin@avantec.net>) |
Ответы |
Re: [HACKERS] SQLJ
|
Список | pgsql-hackers |
Dan Gowin wrote: > > I've just read in DBMS magazine that Oracle, Informix, etc... > are replacing there proprietary Procedural Language's (PL/SQL) with > JVMs (JAVA virtual machine). Apparently according to the database > vendors, this will obviate the need for middle ware products and to > make CORBA much more intuitive. This was a problem that I also wanted to talk about. > My personal opinion is this is yet another mechanism to slow down > the database engine. I don't mind using JAVA in the database engine > as a procedural language, but I think there is still great merit in > breaking > this out as a separate process (Application Server). I don't think that it would be slower than PlTcl for example. Talking about speed: I made some tests with some procedures written in PlPgsql and PlTcl! I understood also that PlPgsql is compiling the procedure body into a sort of bytecodes and the execution is somewhat faster. In PlTcl, I feel (I didn't poke the sources) that a PlTcl procedure body is interpreted each time at execution time. For this reason, it doesn't beneffit from Tcl 8.x compiler, making it slowly than PlPgsql. Am I right ? The first question is : Is Tcl 8.x able to precompile a script and return the bytecodes that should be kept into the database and execute them later? >From this point of view, I think that compiling a Java language procedure and storing the resulting .class might be at execution time as faster as PlPgsql. And , I think, perfectly possible. Right now, I am working at a big project using : 1. Tcl/Tk as thin client 2. Messaging server written in Java as a middle-tier with JDBC 3. PostgreSQL RDBMS It would be perfect from me if PostgreSQL will allow procedures written in Java language. -- Constantin Teodorescu FLEX Consulting Braila, ROMANIA
В списке pgsql-hackers по дате отправления: